Sounds like a classic unhandled poison message problem. When the app reads a message that it cannot process, the message is backed out to the queue. It is then read back in again since it is at the top of the queue. This results in the message appearing to be under syncpoint until finally the listener gives up and stops.
Sometimes the problem is in the app and it is the app explicitly calling ROLLBACK
. Sometimes though the rollback happens befor the app even sees the message. For example, if the message cannot be converted to the local code page, or other low-level error.
If this is what is happening, the answer is to define a backout queue and then alter the input queue to point at it. For example, if the input queue is called SRC.RECEIVER.QUEUE
you might do something like this on the QMgr using runmqsc
:
DEFINE QL(SRC.RECEIVER.QUEUE.BKOUT)
ALTER QL(SRC.RECEIVER.QUEUE) BOQNAME(SRC.RECEIVER.QUEUE.BKOUT) BOTHRESH(15)
If the problem really is a poison message, the problem message will show up in the backout queue as an uncommitted message. As soon as the app issues the next COMMIT
against the source queue, the backout message will become visible in the backout queue. If no other message arrives on the source queue, the poison message will either remain uncommitted in the backout queue or possibly revert to the source queue if ROLLBACK
is called by the app or QMgr.
The setup of the backout queue is simple to do and should be standard practice so I'd recommend doing it whether or not it resolves the problem. Please see Handling poison messages in WebSphere MQ classes for JMS in the Infocenter.