Above is the life cycle of a queued message in a transactional queue and the relevant components. I will explain it below.
- Proxy writes a message to the queue of a service.
- The message is delivered to the service.
- If the message has expired or the maximum retry count has been reached for the message it is moved to the Dead Letter Queue (DLQ).
The Dead letter queue is just another transactional queue.
- The dead letter queue service receives the incoming message.
- It logs the message and the reason it has failed.
- From the settings it decides to either retry the message or kills the message.
- The message has been retried several times and has reached the maximum retry cycle count. At this time the message is marked as poisoned.
- Poisoned message is:
- Either killed or sent to poison queue.
- If delivered to poison queue. The poison service receives the message and logs it.
- Here depending on settings, the Poison service can decide to either attempt to re process the message or to kill it.
- There are more options Fault service and Reject.
The poison queue is not another queue. It is the same queue as where the message originated.
The Admin console provides the following:
- Defines the behaviour of the DLQ service for a specific message operation. (Start new retry cycle or kill message)
- Allows the viewing of a log
- Allows for purging of queues.
- Defines the behaviour of the poison service for a specific message operation. (Start another retry cycle or kill message)
- Transactional queue
- Dead letter queue
- Dead letter queue service
- Poison Queue
- Admin Console
Where to use?
From my own limited use of this it appears as if the dead letter queue and poison queues are to be used in mission critical use cases where a message must be processed. It can be seen as a extension of transactions. Example, a user placed an order and paid for it, a message is sent to the packing and dispatching department. This message cannot be lost. It must be processed.