Configuring balancing behavior using the MQI

To influence precisely when IBM® MQ re-balances applications, certain client application environments can provide information at connect time about the messaging pattern being employed.

In the MQI, the balancing options structure is known as the MQBNO.

If no Balancing Options are provided in your program, supporting clients derive this information in the Application stanza or ApplicationDefaults stanza in the client.ini file deployed alongside the client application.

Note: These stanzas are identical, except the Application version contains a Name field to identify which application these options apply to.

If either form of stanza is supplied, all fields are required to be present except BalanceOptions which is assumed to be none if not explicitly set.

The order of preference for supplying options is:

An MQBNO structure is supplied by the application on CONNX and used in entirety
Or, the matching named Application stanza, if present, is solely used to generate one
Or, the ApplicationDefaults stanza, if present, is solely used to generate one
Or, no MQBNO flows for this connection.

You can supply three key pieces of information from either the MQBNO structure or the client.ini file:

The ApplicationType or pattern of application.
This field indicates to IBM MQ the general pattern of IBM MQ activity in which this application participates.

Three types of application are supported:

Simple

No specific rules should be applied beyond the defaults described in Default application balancing behavior .

Request-Reply

After each MQPUT call, a matching MQGET call is expected for a response message. See Request-reply balancing for more details.

Managed client

Re-balancing requests are always dispatched immediately to the client, which re-balances at a point it considers appropriate, for example, the JEE resource adapter would register in this manner.
The Timeout after which re-balancing can interrupt application activity
Specific BalanceOptions

Request-reply balancing

When the application type is specified as Request-Reply (or MQBNO_BALTYPE_REQREP), one response GET is expected for every PUT the application instance performs. If the application instance involves multiple threads, or deals with requests and responses in batches, multiple requests and responses can be in flight at any given time.

The application is not considered eligible to move, until the number of requests sent is equal to the number of responses received, or the backstop value of MQBNO_BAL_TIMEOUT is exceeded.

An exception to this is when message expiry is configured for a request message. It is assumed that responses should be received within the expiry interval of the request message, and when all request messages have expired, the balancing algorithm no longer waits for additional responses before considering the instance eligible to move.

If multiple requests are outstanding, only the latest expiry among the request messages sent is considered. When meaningful expiry values are in use, you should configure the Timeout balancing parameter for the application to be at least as high a value as any sent message expiry, to avoid cutting short any expected request/response expiry window.

The preceding pattern is only suitable for applications that expect to have periods in which there are no outstanding requests. Complex multi-threaded applications, which constantly send and receive messages,for example, might never become eligible to rebalance under this pattern.

Notes:

No attempt is made to correlate specific requests and responses so, if an earlier response within a batch of in flight messages expires, the application might still wait until the latest request expires before being eligible to balance.
In particular, care is needed if combining MQEI_UNLIMITED and expiring messages, for similar reasons.
If request messages with a limited expiry are outstanding, and new messages are sent with an expiry of MQEI_UNLIMITED, the MQEI_UNLIMITED timeout is not taken into account by the balancing algorithm, which continues to honor the current latest expiry time.

Otherwise, earlier responses having expired could prevent the application from ever being eligible to move. Correspondingly, if MQEI_UNLIMITED replies are outstanding, but expiring requests are subsequently sent, the wait time is reduced to the longest (limited) expiry.

In general, you should avoid a single application instance sending both expiring and non-expiring request messages in a balanced application, as eligibility to rebalance becomes harder for a developer or administrator to accurately track or define.
Only the expiry time specified by the sending application (MQMD.Expiry) is considered when determining how long to wait for replies. Subsequent modifications to this value, for example, use of CAPEXPRY will not effect the wait time.

Examples of when your application might be re-balanced

Example 1

You have written an application that puts messages under syncpoint and commits the batch of messages by issuing an MQCMIT call. When the MQCMIT call completes, the application starts putting messages under a new syncpoint.

Suggested IBM MQ configuration: Default options sufficient
Result: An application instance is moved after an MQCMIT call succeeds (or fails), once the configured number of transactions has been met.
By default, if a batch of messages exceeds 10 seconds, it might be rolled back if a rebalance has been requested. If you expect transactions to regularly exceed this limit and require this to be permitted, you can extend the Timeout appropriately.

Example 2

You have written an application that puts one message to a cluster queue instance, and another application replies to a local temporary dynamic queue with a message, after processing the request. When the request has been destructively read from the local queue the application puts its next request message.

Suggested IBM MQ configuration: Set Type to MQBNO_BALTYPE_REQREP
Result: An application instance is moved when an application completes an MQGET call , at which point the application instance moves to another queue manager. Any subsequent MQPUT calls are carried out on the new queue manager.