Influencing application re-balancing in uniform clusters

With automatic application balancing (a feature of uniform clusters), an application connection can be asked to move to an alternative queue manager at any point in its lifecycle.

Introduction

From IBM® MQ 9.2.4 onwards, the balancing algorithm automatically tries to take into account the state of applications to minimize disruption to application flow. This can be tuned to suit particular applications or application instances by giving IBM MQ additional information about the type of application, or pattern of IBM MQ activity performed by this application.

Usually, the person developing or deploying a client application is likely to be best placed to understand this pattern and supply this information to the queue manager, (see Deploying flexible and scalable client applications) but it might also, or additionally, be tuned by an administrator.

Note that if the queue manager is unable to achieve an even distribution of applications within a reasonable period of time, application connections might still be rebalanced to other queue managers without waiting for a convenient time in their IBM MQ flow.

This can also be tuned to meet requirements. If it is more important to quickly achieve an even distribution of applications, you can configure the product to wait less time to find a suitable time to rebalance an application. Alternatively, if it is more important to prevent disruption to applications, it is possible to configure the product to always wait for a convenient time to move the application.

See Deploying flexible and scalable client applications for further overview information.

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

For .XMS.NET applications, see Properties of ConnectionFactory for more information.

Default application balancing behavior

By default, the transaction/unit of work state of an applications interaction with a queue manager is considered for all applications.

For local transactions, automatic application balancing avoids issuing re-balancing requests to applications that are currently involved in a transaction. While this does not eliminate the possibility of an application receiving a backed out return code, as reaching the configured re-balancing timeout or a genuine outage could still cause such a return code, it does mean that applications will not usually be asked to reconnect while they are in the middle of a transaction.

For applications that begin a new transaction almost immediately after completing the previous one, there might be a delay for the initial call in the new transaction while re-balancing completes. This ensures that automatic application balancing is still able to achieve an even distribution of applications between the queue managers in a uniform cluster.

If you have applications that use longer running transactions you might wish to consider increasing the value of the re-balancing timeout, or disable this constraint entirely. See Configuring the balancing behavior for links on how to control this in the MQI and .NET, or 'Designing client applications for fault tolerance and scalability' for the code level equivalent.

Configuring the balancing behavior

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.

This information is provided in a new structure referred to as Balancing Options.

For the MQI, see Configuring balancing behavior using the MQI.

For the .NET client equivalent of this structure, see Influencing application re-balancing in .NET.

Other client environments do not currently support supplying this structure at connect time.