How do I solve Websphere MQ server queue read race condition?

Question

I have a 4 node websphere application server cluster running some application. The application listens to a queue of websphere mq server. I have created the jms resources in the cluster scope, so all the nodes connect to the same queue manager, and the open input count for the queue is 4 in mq explorer. The problem is if a message is published to the queue, one of the nodes grabs the message and starts processing, but it throws an error saying the message header is incorrect. When I shut down 3 nodes and kept only one running, the application on that node read the message and started processing just fine. I thought that read contention was not a problem in mq, but the facts point to the other direction. Is there some way to set some property in the queue like read lock or something like a scheduler which distributes the messages to 4 nodes fairly ?

Answer 1

If you read the message under syncpoint using a GET instead of a BROWSE, no other thread can retrieve it unless and until ROLLBACK is issued. If the message is OK to process, then issue a COMMIT when done.

On the other hand, if you BROWSE the messages then all threads can retrieve the same message.

Whatever is going on is not attributable to thread contention over the same message somehow corrupting the message. Regardless of whether the message is browsed or destructively retrieved, WMQ assures the integrity and atomic operation of the call. To diagnose this, it will be necessary to have more information as to the exact error you are seeing, including a print of the linked exception which will contain the transport provider's native return code.