So verhindern Sie eine doppelte Zustellung in HornetQ

Question

Wir haben HornetQ nun seit ein paar Wochen untersucht.

In unserem Geschäft haben wir viele "Delta" Nachrichten und (leider ...) sie sind nicht versioniert (und da dies ein internationaler Standard ist, werden sie nicht werden versioniert). Dies bedeutet, dass offensichtlich zweimal die gleiche Nachricht ausgesendet wird. Dennoch bestätigt der Standard, dass dies nicht wirklich vermieden werden kann, und weisen den Absender an, die Nachricht als mögliche Duplikate in diesem Fall zu kennzeichnen.

ich durch HornetQ Dokumentation ausgelagert und es spricht zu vermeiden viel über das Duplizieren vom Server empfangen, aber ich kann nichts über die Vermeidung Herstellung Duplikate finden.

klarer zu sein, die folgende Situation annehmen:

• 1 HQ-Server
• 1 Verbraucher

Im Nenn Szenario nimmt der Verbraucher eine Nachricht in der Warteschlange, schicken Sie es an eine dritte Partei, und beim Empfang der Bestätigung, quittieren Sie die Nachricht an den Server, so dass es aus der Warteschlange entfernt wird.

Jetzt ist der Schwachpunkt hier der ack Teil. Es ist möglich, dass die dritte Partei die Nachricht empfangen und verarbeitet hat, aber (aus irgendeinem Grund) schlägt die Bestätigung fehl und die Nachricht ist nicht aus der Warteschlange.

ich es erkennen, ist nicht möglich, für HQ zu wissen, dass die Nachricht vollständig geliefert wurde, aber ich würde es erwarten, dass die Lieferung zu wissen, wurde bereits versucht und dass es durchaus möglich, dass die Nachricht sein wird ein Duplikat , soweit der Dritte betroffen ist.

Gibt es eine Möglichkeit für den Verbraucher über diese möglicherweise bereits Status ausgegeben informiert werden, so dass es die Nachricht entsprechend kennzeichnen kann?

Answer 1

Eine Möglichkeit besteht darin, einen NAC zu senden (oder einen Fehler an HornetQ zurückzuschicken, wenn die Nachricht im angegebenen Zeitraum nicht von der dritten Partei bestätigt wurde). Wenn die Warteschlange in HornetQ mit Max-Delivery-Versuchen> 0 konfiguriert wurde, führt dies dazu, dass die Nachricht erneut zugestellt wird.

An diesem Punkt kann der Header der Nachricht vom HornetQ-Client für den Parameter "JMSXDeliveryCount" überprüft werden - dies zeigt an, ob die Nachricht zum ersten Mal gesendet oder erneut gesendet wird.

Bei der hier angegebenen Methode wird davon ausgegangen, dass der HornetQ-Client die JMS-API zum Aufrufen der Nachrichten verwendet. Ich bin mir sicher, dass es auch in der Kern-API etwas Entsprechendes geben wird.