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.