Setting configuration timeout values

The integration node receives configuration requests from the IBM® Integration Toolkit and custom integration applications. You can also change its configuration by running several commands, for example, mqsideploy.

Several factors affect the time that an integration node takes to apply and respond to these requests. These factors include the load on the computer on which the integration node is running, network delays between components, and the work that integration servers are performing at the time the request is received. The number of message flows in an integration server, and their complexity, and large message model schema files, might also affect the time that is taken.

You can change the length of time that an integration node can take to perform these actions by using two parameters that you can set on the mqsicreatebroker and mqsichangebroker commands. The combined default value for these parameters is approximately 6 minutes (360 seconds).

During development and test of message flows and integration node configurations, experiment with the values that you set for these timeout parameters to determine appropriate values for your resources.

• -g ConfigurationChangeTimeout

  This value defines the maximum time (in seconds) that is allowed for a user configuration request to be processed, and defaults to 5 minutes (300 seconds). The value is affected by the system load (including processor use), and by the load of each integration server. If the request is not completed in this time, the integration node generates warning message BIP2066, but continues to implement the change. The integration node records further diagnosis information in the system and event logs.

• -k InternalConfigurationTimeout

  This value defines the maximum time (in seconds) that is allowed for an internal configuration change to be processed and defaults to 1 minute (60 seconds). For example, it defines the length of time that the integration node can take to start an integration server before a response is required.

  The integration node starts an internal process to start an integration server and to make all the message flows active. Part of this initialization is performed serially (one integration server at a time), therefore if the change affects more than one integration server, the time required increases. If an integration server exceeds this timeout value, the integration node generates a warning message BIP2080. However, the initialization continues and the integration server is started. The integration node records further diagnosis information in the system and event logs.

The sum of the values of ConfigurationChangeTimeout and the InternalConfigurationTimeout parameters represents the maximum length of time that an integration node can take to process a deployed configuration message before it generates a negative response. Check that typical configurations complete successfully within the time that you specified, to minimize warning messages. If you are using commands that take the timeoutSecs (-w) parameter, set this parameter to the sum of ConfigurationChangeTimeout and InternalConfigurationTimeout values (or higher), to ensure that the command waits long enough to report an accurate completion status for a configuration change. If -w is set to a value that is less than the configuration timeouts for the integration node, then you might see timeouts for configuration changes that successfully complete.

Look for success messages in the Deployment Log in the IBM Integration Toolkit. When success messages are displayed the deployment has completed. If you start a deployment and record how long it takes for the success messages to appear, you can use this time interval as the basis for setting these timeout values.

If the integration node is on a production system, increase the values for both ConfigurationChangeTimeout and InternalConfigurationTimeout parameters to allow for application messages that are currently being processed by message flows to be completed before the configuration change is applied. Also consider increasing the value if you have merged message flows into fewer integration servers that you are using for testing.

If the integration node is on a development or test system, you might want to reduce timeout lengths (in particular, the value of the ConfigurationChangeTimeout parameter) to improve perceived response times, and to force a response from an integration node that is not showing expected behavior. However, reducing the timeout values decreases the probability of deploying a configuration change successfully.

During integration node startup, the InternalConfigurationTimeout parameter is automatically extended based on the number of integration servers which an integration node contains. At this time, the timeout period reported in the BIP2080 warning message may not match the value configured for the InternalConfigurationTimeout parameter.