MQ

 View Only

Introducing Application Patterns In MQ 9.2.4

By Vasily Shcherbinin posted Mon November 22, 2021 08:06 AM

  
Introducing Application Patterns In MQ 9.2.4

In MQ 9.1 CD and MQ 9.2 LTS, we have introduced a new feature called Uniform Clusters, a variation of an IBM MQ cluster that simplifies the setup and the configuration process to create a scalable, highly available MQ topology. Uniform Clusters provide numerous advantages, such as even distribution of client instances across queue managers for load balancing considerations. Uniform Clusters have been embraced by the MQ community and have since become a vital and crucial component in creating scalable and resilient architectures.

A core feature of Uniform Clusters is the ability to rebalance client applications across a group of near identical queue managers. To date, there have been some restrictions to the types of client applications that could utilise and take advantage of this feature – the main restrictions being that applications might be moved to another queue manager at any time and must not have any “affinity” to a particular queue manager if marked as reconnectable. This ruled out many client application types, such as Transactional (multiple messages are put/get under a single unit of work) and Request-Reply (application sends message, reply is provided to a local queue) applications. 

In MQ 9.2.4 we introduce a new concept to address the above and accommodate for a wider spectrum of applications which can take advantage of rebalancing – Application Patterns.

Today, supported application patterns are ‘None’ (plain old fire-and-forget messaging, application can be moved at any time), ‘Transactional’, and ‘Request Reply’– here I’ll give an overview of the new concepts and the Transactional pattern. Request Reply applications are a big enough topic to warrant an entire post of their own. In future, the product may be extended with support for additional application patterns. We’d love to hear your feedback if you have any patterns that you want supported in mind.

So what’s changed?
 
A key difference to existing behaviour is that we now introduce two new concepts into our Uniform Cluster balancing algorithm – transactions and a backstop timeout. Previously applications would be rebalanced without much consideration for the work that they were doing. Now an application will not be rebalanced until it has completed its unit of work. It is also possible to set a ‘backstop’ timeout, after which this instance should be interrupted and moved regardless of subsequent rules. This allows to accommodate for a wide range of different application types, especially where transactions are involved, as it is beneficial to let a transaction complete its work without interruption.
 
It’s also worth mentioning that following our changes, applications that are not blocked by the new changes now typically rebalance more responsively and actively. Look out for a future performance update on the topic to see the improved performance with the new balancing behaviour.
 
Configuring Application Patterns
 
To use the new Application Pattern functionality, the newly added application pattern parameters can be altered client side to configure custom behaviour. If these are not configured, the application pattern parameters take on default values, meaning that applications will not be moved in the middle of a transaction. Configuring Application pattern parameters can either be done programmatically in your client applications, or via the deployment configuration in the mqclient.ini file. Despite all the configurations being done client side, it is important that both the client and server are running MQ 9.2.4 or higher. It’s also worth mentioning that support is currently limited to the MQI and .NET clients at MQ 9.2.4 or higher, but the new default behaviour will apply to back level clients as well.
 
Programmatic configuration
 
If you configure your application programmatically, you can supply the new MQBNO structure via the MQCNO (connections options) structure. The new MQBNO structure can either be supplied via a pointer, or via an offset. Providing both values will result in MQRC_CNO_ERROR (2139).  As these attributes are only relevant to client connections, providing either on any other connection type will also result in MQRC_CNO_ERROR.
 
The above fields provide a memory location for a new structure of type MQBNO, which contains fields to set the Application Type, the Balance Timeout, and the Balance Options.  The structure is ignored entirely unless the application is connecting over a client channel.  Invalid or incompatible BNO parameters will result in new MQRC_BNO_ERROR.

Specifying Application Pattern parameters via BalanceParmsPtr

/* connection/balancing options    */
MQCNO   cno = {MQCNO_DEFAULT};
MQBNO   bno = {MQBNO_DEFAULT};

/* set connection options/version  */
cno.Options |= MQCNO_CLIENT_BINDING;
cno.Options |= MQCNO_RECONNECT;
cno.Version  = MQCNO_VERSION_8;

/* set BalanceParmsPtr             */ 
cno.BalanceParmsPtr = &bno;

/* set Application Pattern fields  */
bno.Timeout = 30;

MQCONNX(QMName,                 
        &cno,                    
        &Hcon,                   
        &CompCode,
        &CReason);​

Deployment configuration in the mqclient.ini file
 
You can also specify the new Application Pattern options for your client applications via the mqclient.ini configuration file. Two new Stanzas have been added to facilitate this: ApplicationDefaults and Application. The ApplicationDefaults stanza refers to all connecting client applications and can be used to specify default parameter values for all applications. The Application stanza can be used to tune parameters for a single application.

Specifying Application Pattern parameters via ApplicationDefaults stanza (mqclient.ini) Specifying Application Pattern parameters via Application stanza (mqclient.ini)
ApplicationDefaults:
 BalanceTimeout=100
 Type=ReqRep
 BalanceOptions=None

Application:
  Name=APP1
  Type=ReqRep
  BalanceTimeout=100
  BalanceOptions=None

Order of precedence
 
The intent is that where an application cannot be modified to use the new balancing options directly, an informed administrator can ‘inject’ the options on the application’s behalf if an up-to-date client library is in use.
 
If either form of stanzas above is supplied, all fields are required to be present except BalanceOptions which will be assumed to be ‘none’ if not explicitly set. 
 
The order of precedence when multiple methods are used to supply Application Pattern parameters can be found in the documentation here.
 
Summary
 
To summarise, the new behaviour introduced should now allow the use of Applications Patterns with Uniform Cluster rebalancing, creating many new opportunities. For example, look here for a detailed overview on how to use the new Application Pattern functionality for the Request-Reply pattern. Additionally, most applications, including the back level ones, should see an improved balancing behaviour straight away.

We are always open to feedback and look forward on your suggestions for what Application Patterns you would like to see us support. As usual please feel free to get in touch either here through the Community (comments on the blog, forums), the MQ RFE process, or any other route you prefer.
​​​​​

Permalink