Poison Messages, Redelivery und die Dead Message Queue in SAP Event Mesh

Eine Nachricht, die der Consumer nicht verarbeiten kann, bleibt in der Queue und wird erneut zugestellt. Ohne Obergrenze wiederholt sich das unbegrenzt, und alle Nachrichten dahinter warten. Dieser Beitrag erklärt, warum Nachrichten scheitern, wie Redelivery und Dead Message Queue in Event Mesh zusammenwirken und welche Einstellungen jede produktive Queue benötigt.

Eine Poison Message ist eine Nachricht, deren Verarbeitung bei jedem Versuch scheitert. Der Consumer holt sie ab, scheitert und bestätigt sie nicht; Event Mesh stellt sie erneut zu. Dieses erneute Zustellen ist die Redelivery. Solange die Ursache besteht, ändert ein weiterer Versuch nichts, und die Nachricht blockiert die Queue.

Mit einer zugewiesenen Dead Message Queue (DMQ) endet die Wiederholung: Nach der eingestellten Zahl von Zustellversuchen wird die Nachricht in die DMQ verschoben, die Hauptqueue ist frei, und die nachfolgenden Nachrichten werden verarbeitet. Laut SAP werden Nachrichten in die DMQ verschoben, wenn die Zahl der Zustellversuche den Max Redelivery Count überschreitet oder ihre Time to Live abgelaufen ist (SAP-Antwort zu Max Redelivery Count und Dead Message Queue).

Nachrichten scheitern selten, weil sie selbst fehlerhaft sind. Die häufigsten Ursachen:

• Das Zielsystem lehnt den Datensatz ab. Ein Pflichtfeld ist leer, ein Wert liegt außerhalb des erlaubten Bereichs, oder ein anderer Vorgang hält eine Sperre auf demselben Objekt.
• Die Nachricht passt nicht zum erwarteten Format. Das Quellsystem hat ein Feld umbenannt oder die Struktur geändert.
• Ein referenziertes Artefakt fehlt. Ein Mapping, eine Wertetabelle oder ein Zertifikat, das der Consumer-Flow referenziert, ist im Zielpackage nicht deployed. Beim Kopieren eines Flows in ein anderes Package werden referenzierte Artefakte nicht mitkopiert.
• Der fachliche Bezug besteht nicht mehr. Der Datensatz, auf den sich die Nachricht bezieht, wurde inzwischen gelöscht oder gesperrt.

In allen vier Fällen bleibt die Ursache bestehen, bis jemand eingreift. Deshalb benötigt die Queue eine Obergrenze für Zustellversuche.

Beim Anlegen einer Queue steht der Max Redelivery Count laut SAP standardmäßig auf 0, und es ist keine Dead Message Queue zugewiesen (SAP-Antwort). Der Wert 0 bedeutet dabei nicht "kein erneuter Versuch", sondern "keine Obergrenze": Eine Poison Message wird unbegrenzt erneut zugestellt, die Queue bleibt blockiert, und im Monitoring erscheint ein Consumer, der ununterbrochen arbeitet, ohne dass der Message Count sinkt.

Wir empfehlen, für jede produktive Queue einen konkreten Wert zu setzen. Fünf Versuche sind ein brauchbarer Ausgangswert: genug, um eine kurze Störung im Zielsystem zu überbrücken, und wenig genug, um die Queue nicht lange zu blockieren.

Die Dead Message Queue ist eine gewöhnliche Queue im selben Namespace, die der Hauptqueue zugewiesen wird. Die Einrichtung besteht aus vier Schritten:

1. Eine zweite Queue im selben Namespace anlegen, etwa acme/crm/prod/customer/created/dmq.
2. An der Hauptqueue diese Queue als Dead Message Queue eintragen.
3. An der Hauptqueue den Max Redelivery Count setzen oder Respect Time to Live aktivieren und eine Time to Live vergeben; ohne eine der beiden Einstellungen wird keine Nachricht in die DMQ verschoben.
4. An der DMQ Respect Time to Live aktivieren und eine Time to Live vergeben, damit sie nicht unbegrenzt wächst. Sieben Tage sind ein Ausgangswert, wenn die DMQ regelmäßig geprüft wird.

Ein Max Redelivery Count an der DMQ selbst ist nicht sinnvoll, weil sie nicht konsumiert, sondern geprüft wird. Event Mesh bietet keine Funktion, Nachrichten aus der DMQ zurück in die Hauptqueue zu verschieben. Nachrichten in der DMQ werden über Consume Messages gelesen; der erneute Versand nach Behebung der Ursache wird über den Ingress-Flow oder die REST-API angestoßen.

Die Dead Message Queue verhindert keinen Fehler, sie begrenzt seine Wirkung. Ohne sie stoppt eine einzige Nachricht die Verarbeitung; mit ihr läuft der Betrieb weiter, aber die fehlerhafte Nachricht ist nicht verarbeitet, und Event Mesh meldet das nicht von selbst. Eine Dead Message Queue ohne regelmäßige Prüfung ist ein Datenverlust mit Zeitverzögerung.

Wir empfehlen deshalb, jeder produktiven Queue eine Dead Message Queue zuzuweisen und deren Message Count zu überwachen, entweder durch eine regelmäßige Prüfung im Cockpit oder durch eine Abfrage über die REST-API von Event Mesh, die bei einem Wert über null eine Benachrichtigung auslöst.