Wie benutze MessageKeyGenerator in StatefulRetryOperationsInterceptor

Question

Ich versuche, Probe Retry-Mechanismus für RabbitMQ mit Spring StatefulRetryOperationsInterceptor zu implementieren.

Wie in der Dokumentation angegeben, muss ich den Nachrichtenschlüsselgenerator einrichten, da die Nachrichten-ID nicht vorhanden ist. Was ich nicht verstehe, ist die tatsächliche Verwendung einer eindeutigen ID, die pro Nachricht generiert wird. das heißt, wenn ich unten Implementierung verwenden ich hatte kein Problem mit Wiederholungs:

StatefulRetryOperationsInterceptor interceptor = 
RetryInterceptorBuilder.stateful() 
      .maxAttempts(3) 
      .backOffOptions(2000, 1, 2000) 
      .messageKeyGenerator(
      new MessageKeyGenerator() { 
       @Override 
       public Object getKey(Message message) { 
       return 1; 
       } 
      ); 
container.setAdviceChain(new Advice[] {interceptor}); 

Answer 1

Stateful Wiederholungs muss die Ursprungsnachricht irgendwie einzigartig sein - so das Wiederholungs „Zustand“ für die Nachricht bestimmt werden kann - der einfachste Weg ist, Der Nachrichtenverleger muss einen eindeutigen Nachrichten-ID-Header hinzufügen.

Es ist jedoch möglich, dass etwas in Ihrem Nachrichtentext oder einer anderen Kopfzeile verwendet wird, um die Nachricht eindeutig zu identifizieren. Geben Sie MessageKeyGenerator ein, um die eindeutige ID zu ermitteln.

Die Verwendung einer Konstante (1 in Ihrem Fall) funktioniert nicht, da jede Nachricht den gleichen Nachrichtenschlüssel hat und alle als Lieferungen derselben Nachricht betrachtet werden (aus einer Wiederholungs-Perspektive).

Das Framework bietet eine MissingMessageIdAdvice, die eingeschränkte Unterstützung für stateful retry bieten kann (wenn sie vor dem Wiederholungsrat der Advice-Kette hinzugefügt wurde). Es fügt der eingehenden Nachricht eine messageId hinzu.

"Eingeschränkt" bedeutet, dass die vollständige erneute Statuswiederherstellung nicht verfügbar ist - nur ein erneuter Zustellversuch ist zulässig.

Wenn die erneute Zustellung fehlschlägt, wird die Nachricht zurückgewiesen, was dazu führt, dass sie verworfen oder an den DLX/DLQ weitergeleitet wird, wenn sie so konfiguriert ist. In allen Fällen wird der "temporäre" Zustand aus dem Cache entfernt.

Im Allgemeinen, wenn volle Wiederholungsunterstützung benötigt wird und es keine messageId Eigenschaft gibt und es keine Möglichkeit gibt, einen eindeutigen Schlüssel mit einer MessageKeyGenerator zu generieren, würde ich stateless retry empfehlen.