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.3.0, 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.

[MQ 9.4.0 Jun 2024] For JMS Applications, see Influencing application re-balancing in IBM MQ classes for JMS for further 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 want 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.

Request-reply balancing

When the application type is specified as Request-Reply, 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 the 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 an unlimited expiration time and expiring messages, for similar reasons.
If request messages with a limited expiry are outstanding, and new messages are sent with an unlimited expiry time, the unlimited expiry 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 unlimited expiry timeout 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 ( for example, in the MQI the value of 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.

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.

[MQ 9.4.0 Jun 2024] For the JMS approach to setting these options, see Influencing application re-balancing in IBM MQ classes for JMS for further information.

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