Was passiert, wenn eine Nachricht in MQ zurückgesetzt wird?

Question

Ich erhalte eine Nachricht von einer WebSPhere MQ-Warteschlange. Ich versuche zu verarbeiten, und wenn ich einige Ausnahmen erhalte, möchte ich die Nachricht in die MQ-Warteschlange zurücksetzen.

Ich habe keine Probleme, das gleiche zu tun. Was passiert mit der Nachricht? Geht es zum Ende der Warteschlange?

Wenn ich versuche, eine Nachricht aus der Warteschlange zu ziehen, würde ich die gleiche Nachricht erhalten, dass ich rollte?

Wie ist das Verhalten wahrscheinlich? Ich möchte dieses Verhalten normalerweise in einem Warteschlangenszenario mit hohem Volumen kennenlernen.

Schätzen Sie alle Eingaben.

Danke, Manglu

Answer 1

Wenn Sie Queue-Operationen im Rahmen einer Transaktion zu tun sind, und ein Rollback auftritt, dann, nachdem die Transaktion in die Warteschlange und die Nachricht wie auch schon vor Beginn der Transaktion erscheint aufgelöst wird. Mit anderen Worten, keine Änderungen.

In einem High-Volume-Szenario ist es jedoch typisch, mehrere transaktionale Leser und Schreiber in einer einzigen Warteschlange zu haben, und sie sperren nicht die gesamte Warteschlange für jede Warteschlange oder Enqueue.

Diese Leser und Schreiber werden Elemente in die Warteschlange einfügen oder Elemente aus der Warteschlange transaktionsmäßig aus der Warteschlange entfernen, während Ihre verlorene Transaktion aufgelöst wird. In diesem Fall können andere Warteschlangenelemente erscheinen oder verschwinden (oder beides).

Wenn nach Rollback der ursprünglichen Transaktion, Sie wieder aus der Warteschlange austreten, können Sie erhalten Sie die ursprüngliche Nachricht, aber Sie können nicht. In einem Szenario mit hohem Volumen und hohem Zugriff ist es möglich, dass ein anderer Leser die Nachricht abgerufen hat, bevor Ihr Code dies tun kann.

Answer 2

Rollback lässt die Nachricht in der Warteschlange und stellt sie für die erneute Zustellung auf.

Wenn jedoch ein (konfigurierbares) Limit für erneute Zustellversuche erreicht wurde, wird die Nachricht in der "Warteschlange für nicht zustellbare Nachrichten" abgelegt.

Ein typisches Beispiel, wo dies geschieht, sind s.c. 'poison messages': Nachrichten, die aufgrund fundamentaler und nicht vorübergehender Probleme (wie ungültiges Format, fehlende Felder usw.) nicht behandelt werden können.

Bevor Sie also ein Rollback durchführen (und die Nachricht in die Warteschlange stellen), sollten Sie darüber nachdenken, ob der Fehler vorübergehend ist (wie bei Verbindungen zum Backend) oder nicht.

Im letzteren Fall ist es am besten, die Nachricht zu verschlucken und einen Fehler zu protokollieren oder einen anderen Alarm auszulösen. Andernfalls verbraucht die Nachricht unnötigerweise sowohl die Verarbeitungsleistung als auch die Warteschlangeninfrastruktur.

HTH

Guy

Answer 3

ein paar der spezifischen Punkte aus diesem Thread zu beantworten ...

• Die Botschaft behält seine Position in der Warteschlange. GET unter dem Synchronisationspunkt sperrt die Nachricht, entfernt sie jedoch nicht aus der Warteschlange oder ändert ihre Position nicht. Rollback gibt die Sperre frei und macht die Nachricht für die erneute Zustellung verfügbar.
• Das automatische Requeueing einer Poison-Nachricht erfolgt mit den JMS- und XMS-Klassen, nicht aber mit den nativen Java-, C-, C# -, COBOL- usw. APIs. Wenn Sie nicht JMS oder XMS (das die JMS-API für C- und .Net-Programme implementiert) verwenden, müssen Sie die Nachricht selbst erneut anfordern.
• Sie haben Korrekt, dass die erneute Eingabe in die Warteschlange versucht wird, die im BOQNAME-Attribut der Eingabewarteschlange benannt wurde, nachdem BOQTHRESH-Neuzustellungen überschritten wurden. Wenn diese Warteschlange nicht verfügbar ist (voll, nicht autorisiert, nicht existent usw.), wird die DLQ versucht. Wenn dies fehlschlägt, hört der Nachrichten-Listener auf, Nachrichten vollständig zu empfangen.
• Idealerweise behandelt ein Programm eine Poison-Nachricht, indem es sie erneut aufruft und auf das Vorhandensein von Nachrichten in der Exception-Queue aufmerksam macht. Wenn dies nicht gelingt, konsumieren und verwerfen Sie die Nachricht zumindest nicht. Loggen Sie es zusammen mit den Nachrichtenheadern ein, damit jemand später abstimmen kann, was mit ihm passiert ist.