[UNIX, Linux, Windows, IBM i]

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:
  1. An MQBNO structure is supplied by the application on CONNX and used in entirety
  2. Or, the matching named Application stanza, if present, is solely used to generate one
  3. Or, the ApplicationDefaults stanza, if present, is solely used to generate one
  4. 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:
  1. 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.
  2. The Timeout after which re-balancing can interrupt application activity
  3. Specific BalanceOptions

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.