How to receive notification when IBM Queue Manager gets disconnected?

We are currently building an application that needs to communicate to some IBM WebSphere queues. At the other end of the queues there is another world. Due to some unknown circumstances (for me), connecting to the MQQueueManager takes 17 seconds every time, but sending and receiving messages afterwards through the queues is not a time consuming job. As we are placing now a web service in front of the WebSphere, we came up with the idea of decorating and caching the MQQueueManagers and the MQQueues and verifying before each message sending if they are connected, respectively open; if not, we try connecting to the MQQueueManager, repectively opening the MQQueue (once again, connectiong to the MQQueueManager takes 17 seconds, opening the MQQueue is "instant"). So we are expecting that every once in the while WebSphere would disconnect the MQQueueManager (I cannot tell for sure as we cannot h开发者_StackOverflow社区eavily test this for now, but we should be cautious) and the unlucky calling program would wait 17 seconds to reconnect. As things stand now, we cannot predict the occurence of this thing to happen. Our current implementation uses the WebSphere MQ classes for .NET. Is there any possibility for us to receive a callback notification when the MQQueueManager gets disconnected or the associated queues are closed?

Yes! If you use the latest WMQ .Net classes and the latest IA9H SupportPac you get an asynchronous callback method. (This comes with .Net sample code showing how to register and use the callback.) It is my understanding that this method will pass your callback routine a message when one is available or else pass an exception to the registered exception listener if the connection is lost or queue is set to GET(DISABLED).

Get the latest WMQ Client here. Look for SupportPacs with names like MQC*. The v8.0 client is MQC8, the v9 client is MQC9, etc.

If you have an older version of .Net WMQ classes and can't upgrade for some reason you can always keep a separate thread open and periodically poll the queue. Don't poll too frequently, though. In the past I've seen people use a class variable as a countdown timer. Each time a message is successfully retrieved or put to the queue, the timer is reset to its max. When the timer reaches zero, poll the queue. This way you only poll the queue when no other traffic is on the connection.