Influencing application re-balancing in IBM MQ classes for JMS
From IBM® MQ 9.3.4, additional constants are available for you to set the balancing option properties on a ConnectionFactory. These constants are only applicable if the WMQ_PROVIDER_VERSION is set to 7. Request_reply applications in a uniform cluster must allow for the possibility of missed replies.
The constants available
- Re-balancing application type
- The type of balancing action; represented by the constant
WMQConstants.WMQ_BALANCING_APPLICATION_TYPE
- You must use this property to set the ApplicationType field of the MQBNO structure.You must set values of type integer. These are the possible values:
- WMQConstants.WMQ_BALANCING_APPLICATION_TYPE_SIMPLE (default)
- Simple balancing; no specific rules are applied in addition to those described in Influencing application re-balancing in uniform clusters.
- WMQConstants.WMQ_BALANCING_APPLICATION_TYPE_REQUEST_REPLY
- Request-Reply balancing; after each MQPUT call, a matching MQGET call is expected for a response message. Balancing is delayed until such a message is received, or the request message EXPIRY has been exceeded.
- You must use this property to set the ApplicationType field of the MQBNO structure.
- Re-balancing options
- The balancing options set by the issuing application; represented by the constant
WMQConstants.WMQ_BALANCING_OPTIONS
- You must use this property to set the BalanceOptions field of the MQBNO structure.You must set values of type integer. These are the possible values:
- WMQConstants.WMQ_BALANCING_OPTIONS_NONE (default)
- No options are set.
- WMQConstants.WMQ_BALANCING_OPTIONS_IGNORE_TRANSACTIONS
- Setting this option allows applications to be rebalanced even if in the middle of a transaction.
- You must use this property to set the BalanceOptions field of the MQBNO structure.
- Re-balancing timeout
- The timeout after which re-balancing might interrupt application activity; represented by the
constant WMQConstants.WMQ_BALANCING_TIMEOUT
- You must use this property to set the Timeout field of the MQBNO structure.You must set values of type integer. These are the possible values:
- WMQConstants.WMQ_BALANCING_TIMEOUT_AS_DEFAULT (default)
- The set default timeout value. By default, this value is 10 seconds.
- WMQConstants.WMQ_BALANCING_TIMEOUT_IMMEDIATE
- Immediate timeout occurs.
- WMQConstants.WMQ_BALANCING_TIMEOUT_NEVER
- No timeout occurs.
- a value between 1 and 999999999
- This represents a value in seconds.
Note: You must provide one value only from the defined values, or a value of 0-999999999 seconds.
- You must use this property to set the Timeout field of the MQBNO structure.
These properties are also settable in the JNDI representations of Connection Factories using either the JMSAdmin or IBM MQ Explorer interfaces.
The potential for lost messages at balancing of REQUEST_REPLY applications
In IBM MQ classes for JMS (and IBM MQ classes for Jakarta Messaging), request/reply functionality is implemented by setting the JMSReplyTo property on the request message, which is used by the responding application to determine whether the reply is sent. In JMS terms the JMSReplyTo property is a Destination.When this is translated into IBM MQ operations, the JMSReplyTo property is sent as a fully-qualified queue URI - identifying a queue on a specific queue manager.
Due to the asynchronous nature of the handling of balancing re-connections, a re-connection might be initiated after the JMSReplyTo property has been translated to a fully qualified URI, but before the request message has been put to the request queue. Under these circumstances, the responding application might send its response to the original reply queue on the original queue manager, but the requesting application might now be waiting for a reply on the new queue manager.
Request_reply applications in a uniform cluster must therefore allow for the possibility of missed replies.