One of the problems that a JMS programmer is always faced with is a connectivity issue. The issue could be that the server is going through a scheduled restart or there is a network issue. As a JMS programmer one needs to ensure that the client program needs to close the dangling connection objects and attempt reconnect to the WebSphere MQ queue manager at regular intervals in most of the cases.
With automatic JMS client reconnect feature in WebSphere MQ JMS Client, the task is very simple as the WebSphere MQ JMS client itself will reconnect to the MQ queue manager. When the WebSphere MQ high availability setup is done on the server side, more benefit of this feature can be seen. Even with one single queue manager on the server the feature can be used. The requirement to use this feature is to have 7.0.1 version (recommended with latest fixpack) on the client and the server side.
Its easy to enable an existing JMS application to use this feature. Its just a simple connection factory parameter that enables this feature. The connection factory setting could be done either using JNDI provider or programmatically or even the CCDT. Here in this example, we'll do it programmatically:
MQConnectionFactory mqconnfact = new MQConnectionFactory();
conn = mqconnfact.createConnection();
This code snippet will ensure that the client will keep attempting a reconnect to MQQM queue manager for 600 seconds and then give up.
Impact on Receiver
Now let's get more deeper into understanding the impact of the feature on the JMS receiver. If the auto-reconnect feature is not used, the JMS message listener would normally cause the exception listener to be invoked with the connectivity issue is experienced. Now with this feature, the WebSphere MQ JMS client will internally attempt a reconnect to the queue manager, so the user or the programmer doesn't get to know that there is a connectivity issue. This simplifies the exception handling to a large extent.
Impact on Sender
A JMS message producer is also benefited with this feature. Let's say you are sending message and there is a connectivity issue. If the feature is not used, you will get a JMS exception and the client would need to close the dangling connection object and try reconnecting. Now with this feature enabled, the MessageProducer.send() API call would block until the connectivity is back or the reconnect time expires. This ensures that the JMS client does not need to do any exception handling and let the MQ JMS client handle the reconnect to the queue manager.
When the WebSphere MQ High Availability setup is done, the connection name list parameter needs to be used instead of the hostname and port name parameters in the connection factory. The blog by Valerie Lampkin in AIMSupport discusses about the multi-instance queue manager.
Disclaimer: Each posting on this site is the view of its author and does not necessarily represent IBM’s positions, strategies or opinions.