The number of concurrent MQ connections in DataPower's MQ front-side handler (FSH).
How does "The number of concurrent MQ connections" field in a DataPower appliance's MQ FSH behave?
The name "concurrent connections" is a misnomer with respect to the behavior of the MQ FSH. It represents the number of active and pending MQGETs for the front side GETQ.
Think of this setting in terms of how many MQ connections the MQ FSH will use to poll the GETQ for requests which will include both the active MQGET as well as pending MQGET(s).
What is the difference between polling and using MQ connections? The answer depends on how the MQ FSH processes the message from the GETQ. Assume that the MQ FSH is configured to use the number of concurrent connections as 1 in the MQ FSH.
- The MQ FSH polls for the request with the MQ connection (hereinafter referred to as C1).
- After the messages is returned from the GETQ, DataPower starts processing the message which may involve MQPUT. This will take additional connection if MQ FSH and backend MQ URL use different mq-qm objects. However, the connection (C1) will be shared with the backend MQ URL if both front side and backend use the same mq-qm object and units of work is enabled.
- In the mean time the MQ FSH will continue MQGET(s) which may remain in pending states. This will increase the number of concurrent connections for the MQ FSH greater than 1. After the processing of all messages, this value will become as 1 once the cache time-out period is expired.
In the above example, note that even setting concurrent connections = 1 on the MQ FSH, the MQ FSH still can use at least 2 MQ connections (C1 is used for transaction processing, C2 is used to poll for request). That is, there are 2 connections used by the MQ FSH and one of them is used to poll the request from the GETQ.
- How many connections could the MQ FSH possibly use? The answer depends on how long it takes to process the transaction in DataPower (in request rule, backend and response rule). Under an extreme condition, if transaction processing takes longer than the front side time-out, and there are many messages in the GETQ, then the MQ FSH can use as many connections as it is allowed by the connection pool (configured in the mq-qm object's total connection limit) to process these messages. In other words, if the request messages arrives at the GETQ with a low arrival rate, then MQ FSH will keep the number of used connections low.
- How should one set the number of concurrent connections? In most use cases, default value (=1) should be sufficient. Setting it to a value greater than 1 may yield some performance gain, but the difference is marginal. If message ordering is required, then it must use a value of 1 as multiple MQGETs will break message ordering.
More support for:
IBM DataPower Gateways
Software version: 4.0.2, 5.0.0, 6.0.0, 6.0.1, 7.0.0
Operating system(s): Firmware
Software edition: Edition Independent
Reference #: 1516288
Modified date: 30 September 2011