Ensuring that all DLQ messages are processed

The dead-letter queue handler keeps a record of all messages on the DLQ that have been seen but not removed. Ensure that the DLQ contains as few messages as possible.

About this task

If you use the DLQ handler as a filter to extract a small subset of the messages from the DLQ, the DLQ handler still keeps a record of those messages on the DLQ that it did not process. Also, the DLQ handler cannot guarantee that new messages arriving on the DLQ are seen, even if the DLQ is defined as first-in-first-out (FIFO). If the queue is not empty, the DLQ is periodically re-scanned to check all messages.

For these reasons, you should ensure that the DLQ contains as few messages as possible. If messages that cannot be discarded or forwarded to other queues (for whatever reason) are allowed to accumulate on the queue, the workload of the DLQ handler increases and the DLQ itself is in danger of filling up.

To enable the DLQ handler to empty the DLQ, take the following measures:

• For messages that you would otherwise ignore, use an action that moves the messages to another queue.

  Try not to use the ACTION (IGNORE) command, which leaves messages on the DLQ - and remember that ACTION (IGNORE) is assumed for messages that are not explicitly addressed by other rules in the table. Instead, use an action that moves the messages to another queue. For example:

  ACTION (FWD) FWDQ (IGNORED.DEAD.QUEUE) HEADER (YES)
  

• Make the final rule in the table a catch-all to process messages that have not been addressed by earlier rules in the table.

  For example, the final rule in the table could be something like this:

  ACTION (FWD) FWDQ (REALLY.DEAD.QUEUE) HEADER (YES)
  

  This forwards messages that fall through to the final rule in the table to the queue REALLY.DEAD.QUEUE, where they can be processed manually. If you do not have such a rule, messages are likely to remain on the DLQ indefinitely.