Poison messages, redelivery and the dead message queue in SAP Event Mesh

A message the consumer can't process stays in the queue and is delivered again. Without an upper limit that goes on indefinitely, and every message behind it waits. This article explains why messages fail, how redelivery and the dead message queue work together in Event Mesh, and which settings every productive queue needs.

A poison message is a message whose processing fails every time. The consumer picks it up, fails and doesn't acknowledge it, so Event Mesh delivers it again. That repeated delivery is the redelivery. As long as the cause persists, another attempt changes nothing, and the message blocks the queue.

With a dead message queue (DMQ) assigned, the repetition ends: after the configured number of delivery attempts, the message is moved to the DMQ, the main queue is free again and the messages behind it are processed. According to SAP, messages are moved to the DMQ when the number of delivery attempts exceeds the max redelivery count or their time to live has expired (SAP answer on max redelivery count and dead message queue (opens in a new tab)).

Messages rarely fail because there is something wrong with the message itself. The usual causes:

• The target system rejects the record. A mandatory field is empty, a value is out of range, or another transaction holds a lock on the same object.
• The message doesn't match the expected format. The source system renamed a field or changed the structure.
• A referenced artifact is missing. A mapping, a value table or a certificate that the consumer flow references isn't deployed in the target package. When you copy a flow to another package, referenced artifacts don't come with it.
• The business object no longer exists. The record the message refers to has since been deleted or locked.

In all four cases the cause stays until someone fixes it. That is why the queue needs an upper limit on delivery attempts.

When you create a queue, the max redelivery count is 0 by default and no dead message queue is assigned (SAP answer (opens in a new tab)). A value of 0 doesn't mean "no retry"; it means "no limit". A poison message is redelivered indefinitely, the queue stays blocked, and in monitoring you see a consumer working non-stop while the message count never drops.

We recommend setting an explicit value for every productive queue. Five attempts are a good starting point: enough to ride out a brief disruption in the target system, and few enough that the queue isn't blocked for long.

The dead message queue is an ordinary queue in the same namespace that you assign to the main queue. Setup takes four steps:

1. Create a second queue in the same namespace, for example acme/crm/prod/customer/created/dmq.
2. On the main queue, enter that queue as the dead message queue.
3. On the main queue, set the max redelivery count, or enable Respect Time to Live and set a time to live. Without one of the two, no message is ever moved to the DMQ.
4. On the DMQ, enable Respect Time to Live and set a time to live so it doesn't grow forever. Seven days is a reasonable starting point if someone checks the DMQ regularly.

A max redelivery count on the DMQ itself makes no sense, because the DMQ is inspected, not consumed. Event Mesh has no function for moving messages from the DMQ back into the main queue. You read them via Consume Messages, and once the cause is fixed, you resend them through the ingress flow or the REST API.

The dead message queue doesn't prevent a fault; it contains it. Without one, a single message stops all processing. With one, processing continues, but the failed message hasn't been processed and Event Mesh won't tell you on its own. A dead message queue nobody checks is data loss on a delay.

We therefore recommend assigning a dead message queue to every productive queue and monitoring its message count, either by checking the cockpit regularly or by querying the Event Mesh REST API (opens in a new tab) and raising an alert when the count is above zero.