This article covers the situation where IBM App Connect Enterprise is dropping MQ connections and then immediately reconnecting, causing excessive authentication processing and CPU load on both client and server.

Scenario

Integration flows that receive messages in a wide variety of sizes through an MQInput node, leading to MQ connections being dropped in order to shrink the MQ message buffer size. The evidence is seen in the activity log of the Message flow as “Disconnected” followed by connecting again immediately.

Procedure

Check to see if the flows are disconnecting often and then change the configuration to fix the issue (Unix Environment):

1. Creating Activity logs
   
   
1. Create the Activity log policy file:
   
   /var/mqsi/components/<Broker_Name>/servers/<IS_Name>/overrides/DefaultPolicies/<Activity_Message_Flow.policyxml>
   
   
2. Verify and update the parameter in the file. If the file does not exist, either copy it from another Integration Server or create a new file and copy the content below and update the values.
   
   

   <?xml version="1.0" encoding="UTF-8"?>

   <policies>

     <policy policyType="ActivityLog" policyName="Activity_Message_Flow" policyTemplate="ActivityLog">

       <enabled>true</enabled>

       <filter>RM=MQ</filter>

       <minSeverityLevel>INFORMATIONAL</minSeverityLevel>

       <fileName>/om/ACE_name/Integration_Server /MQActivity.txt</fileName>

       <numberOfLogs>10</numberOfLogs>

       <maxAgeMins>1440</maxAgeMins>

       <maxFileSizeMb>250</maxFileSizeMb>

       <formatEntries>true</formatEntries>

     </policy>

   </policies>

   
   
   
3. Restart the Integration Server, and monitor the activity log under load.
   
   Run the following command three times with a 5 minute interval: grep Disconnected MQActivity.txt |wc -l
   
   If the values are different (and increasing), then flows may be disconnecting for buffer size reasons. To verify this, examine the file to see if there is a pattern of threads disconnecting and then connecting again immediately. Note that idle threads will disconnect under normal circumstances but will only reconnect when the thread is needed again; they will not disconnect and immediately reconnect.
   
   If the values are increasing and the disconnect/reconnect pattern is visible, then proceed to step 2; if not, then investigate other possible reasons for excessive connections being made, such as threads freeing connections when returning to the thread pool, etc.
   Consider changing ConnectorProviders.sharedConnectorIdleTimeout in server.conf.yaml if the default value of 60 seconds is too low, or using the “Start additional instances when the flow starts” property associated with the message flows.
   
   
2. Setting up the profile script directory.
   App Connect Enterprise can run profile scripts before starting integration servers, and this allows the setting of environment variables.
   See https://www.ibm.com/docs/en/app-connect/12.0?topic=tasks-setting-up-command-environment for more details.
   The profiles directory is not created by default, and must be created in advance. For example, create the <profiles> folder for the server TEST_SERVER in the following path:
   
   

   /var/mqsi/config/<Broker_Name>/TEST_SERVER/profiles

3. Create the file buffer.sh in the profiles directory and add the following entry (possibly increasing the threshold if some messages are larger than 16MB) and save the file. Ensure the file is executable (possibly setting permissions to 777).
   
   export MQSI_MQINPUT_BUFFER_MONITORING_THRESHOLD=16777216
   
   
4. Restart the Integration Server to pick up the new environment variable.
   
   
5. To verify the successful use of the buffer.sh profile script, make sure Broker_Name.TEST_SERVER.profilelog in /var/mqsi/common/log has been updated with the value set as;
   
   (MQSI_MQINPUT_BUFFER_MONITORING_THRESHOLD=16777216)
   
   
6. Execute the command 3 times with a 5 minute interval: grep Disconnected MQActivity.txt |wc -l to observe how many times the flows disconnect.
   
   There should be no threads disconnecting and then connecting again immediately, though idle threads will disconnect under normal circumstances.
   
   Thanks to Trevor Dolby for his input to this article.

#AppConnectEnterprise(ACE)