jms message not moving of the queue in websphere

I have a message driven bean that throws exception under certain conditions. When it throws an exception the message is not processed and put back on the queue. From what I understand with MQ and WAS (Websphere Application Server) the message should be marked as bad after x number of tries and removed from the queue. This is not happening and the message remains on the queue marked as bad.

What part of the configuration in MQ and/or WAS 开发者_StackOverflow社区have I missed to set correct?

(The issue with the MDB throwing exceptions is NOT the point here)

Thanks.

On the queue there are attributes BOQNAME and BOQTHRESH. These must be set to the name of the backout queue where the message is to be requeued and the threshold for number of backouts before requeueing the message.

In addition, the QMgr must be able to put the message onto the designated queue. Problems may include misspelling of the queue name, the backout queue being full or the account running the MDB was not authorized to put messages on the backout queue.

If the MDB detects a poison message loop and has nowhere to requeue the message, it stops processing. You will still see the thread but you will be missing one or more open input handles on the queue. The app must be restarted to revive it in this instance.

Avoid using the system's DLQ for the backout destination. The DLQ is where the QMgr will place messages arriving from another QMgr which cannot resolve to a destination queue. These will have a Dead Letter Header attached whereas MDB messages that are requeued will not. This can cause problems with any automation you have watching the DLQ. Therefore, it is advisable to have an exception queue per application that is not the DLQ.

BOQTHRESH should be greater than 1 or 2 because normal operations such as shutdown of the QMgr or channel can result in a backout. I generally set BOQTHRESH to 5 or 10 but have seen people set this much higher. Depends on your tolerance for retries and whether the backouts are typically caused by transient conditions such as filling up log extents.

Look at this How WebSphere handles poison messages article.
It applies to WAS 5, but the principles have not changed.