Change timeouts that affect configuration tasks in the broker.
Before you start:
Read Deployment overview to understand the conditions under which these timeouts apply.
Several factors affect the time that a broker takes to apply and respond to these requests. These include the load on the broker's computer, network delays between components, and the work that execution groups are performing at the time the request is received. The number of message flows in an execution group, and their complexity, also affect the time taken.
You can change the length of time that a broker can take to perform these actions using two parameters that you can set on the mqsicreatebroker and mqsichangebroker commands. The combined default value for these parameters is approximately six minutes (360 seconds).
During development and test of message flows and broker configurations, experiment with the values that you set for these timeout to determine appropriate values for your resources.
This value defines the maximum time (in seconds) that is allowed for a user configuration request to be processed, and defaults to five minutes (300 seconds). The value is affected by the system load (including processor use), and by each execution group's load. If the request is not completed in this time, the broker generates warning message BIP2066, but continues to implement the change. The broker records further diagnosis information in the system and event logs.
This value defines the maximum time (in seconds) that is allowed for an internal configuration change to be processed and defaults to one minute (60 seconds). For example, it defines the length of time that is allowed for the broker to start an execution group before a response is required.
The broker starts an internal process to start an execution group and to make all the message flows active. Part of this initialization is performed serially (one execution group at a time), therefore if the change affects more than one execution group the time required increases. If an execution group exceeds this timeout, the broker generates a warning message BIP2080. However, the initialization continues and the execution group is started. The broker records further diagnosis information in the system and event logs.
The sum of the ConfigurationChangeTimeout and the InternalConfigurationTimeout represents the maximum length of time that a broker 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 have specified, to minimize warning messages. Look for warning messages in the Broker Administration perspective in the Alerts view. When all messages disappear, the deployment has completed. If you start a deploy and record how long it takes for all messages to disappear from the Alerts view, you can use this time interval as the basis for setting these timeout values.
If the broker is on a production system, increase the values for both ConfigurationChangeTimeout and InternalConfigurationTimeout 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 execution groups that you are using for testing.
If the broker is on a development or test system, you might want to reduce timeouts (in particular, the ConfigurationChange Timeout) to improve perceived response times, and to force a response from a broker that is not showing expected behavior. However, reducing the timeout values decreases the probability of deploying a configuration change successfully.