Developing flexible and scalable client applications

For fault tolerance and scalability, deploying client applications which support connections options into uniform clusters allows the instances of the application to be rebalanced between queue managers.

See About uniform clusters for an overview of uniform clusters.

Ideally, this re-balancing is invisible to the application, but only certain types of application are suitable for this type of deployment, and some consideration might be needed in the application design.

These considerations fall into two main categories:

Rare error paths which might exist already for re-connectable applications, but become more likely when deployed into a uniform cluster. For example, following a reconnect, any inflight unit of work is backed out, and browse cursors reset. These might be a rare event for your re-connectable application in its current environment and, therefore, not handled as cleanly as possible by the application code. Reviewing application logic, to ensure appropriate handling is in place for such situations, helps avoid unexpected issues arising.
Affinities to a particular queue manager. If you know that an application must always connect back to the same or a specific queue manager, the application should be configured to reconnect to that queue manager, or not have its connection to that queue manager enabled. However, these affinities might be temporary, such as waiting for a response message. Influencing the balancing algorithm to account for these affinities from the application code is discussed in the following section. For more details on these options, and how to achieve a similar approach through configuration, rather than application code, see Influencing application re-balancing in uniform clusters.

Influencing reconnection options in the MQI

See Reconnection options for more information on MQCNO_RECONNECT.

If you know that an application must always connect back to the same or a specific queue manager, it should be configured as MQCNO_RECONNECT_Q_MGR or MQCNO_RECONNECT_DISABLED.

Influencing the balancing algorithm in the MQI

However, you might want to control or influence that re-balancing behavior to suit the needs of specific types of application; for example, minimizing interruptions to in flight transactions, or ensuring requester applications receive their responses before being moved.

Certain default desirable behaviors are assumed and discussed in Influencing application re-balancing in uniform clusters. You can also influence the behavior for specific applications at configuration or deployment time through the client.ini file as discussed in that topic.

In other situations, it might make more sense to make the balancing behavior and requirements part of the application logic. In these cases, the same relevant characteristics of the application can be supplied to IBM® MQ when connecting to the queue manager on the MQCONNX call, in a structure called MQBNO (balancing options).

If you provide an MQBNO structure, it must supply all of the information required by IBM MQ to make a decision about how and when the application should be asked to reconnect to a different queue manager.

You must supply:

The Type of application
The Timeout at which the instance is rebalanced regardless of state
Any special BalanceOptions

The exception to this, is that you can leave the timeout as MQBNO_TIMEOUT_DEFAULT if required. In this case, the timeout resolves to any value in the client.ini file, application, or global stanzas, if provided, and failing that, to the base default of 10 seconds.

See MQBNO for details on the format of this structure.

For .NET applications, see Influencing application re-balancing in .NET for further information.