A poisoned message is a messages that kills the application. This may be as simple as having unexpected data in a field, or simply a bug in the application which is hit when the message is processed.
The classic scenario is
- Abend taking a dump
Symptoms are typically thousands of dumps, or the application draining all of the CPU from an engine (think black hole).
I have seen this problem suddenly disappear – because the message expired after 30 seconds. This caused much head scratching as they started investigating the problem, and the problem went away.!
What can you do about this?
For JMS the work is done for you. See here.
The BackoutCount field in the MQMD is a count of the number of times the message has been backed out. This is usually 0.
You should have logic which says if BackoutCount > 1 then do special processing.
Use MQINQ on the queue name to find the queue type. If the queue type is a QALIAS you need the name of the base queue.
Use MQINQ on the base queue to inquire BOQNAME and BOTHRESH
If MQMD.BackoutCount >= BOTHRESH and BOQNAME != ' ' then do create a header for the message use MQPUT1 to put the message to the BOQNAME end else write the message to the DLQ with the appropriate header Produce an alert to notify the applications team that there was a problem, and give date time, and any message identifier such as MSGID and Correlid
Then fix the underlying problems!