Bereinigen verzögerter Nachrichten auf Azure Service Bus ohne die Sequenznummer

Question

Gibt es eine Möglichkeit, eine verzögerte Nachricht auf Azure Service Bus wiederherzustellen oder zu löschen, wenn ich die Sequenznummer verloren habe? Das Szenario lautet: Ich möchte BrokeredMessage.Defer() verwenden, um eine Nachricht zu verzögern. Ich plane, die Sequenznummer aufzuzeichnen und sie später zum Abrufen der Nachricht zu verwenden. Aber wenn etwas schief geht - sagen wir mal, dass ein Buggy-Code eingesetzt wird - und die Sequenznummer nicht richtig aufgezeichnet wird, scheint diese Nachricht auf dem Servicebus in einem verzögerten Zustand zu sitzen, bis die Nachricht abläuft, was für immer sein könnte.

Dies betrifft mich hauptsächlich, weil diese Nachricht Speicherplatz in der Warteschlange oder Subskription belegen wird, und ich habe keine Möglichkeit gefunden, diesen Speicherplatz wiederherzustellen, ohne die Warteschlange/Subskription vollständig zu löschen.

Gibt es eine beliebige Möglichkeit, "verlorene" zurückgestellte Nachrichten entweder zu empfangen oder zu löschen?

Answer 1

Wenn Nachrichten aus einer Warteschlange oder einem Abonnement abgerufen werden, werden auch zurückgestellte Nachrichten zurückgegeben. Zurückgestellte Nachrichten haben State = "Deferred".

Auf diese Weise können Sie die Sequenznummern der zurückgestellten Nachrichten abrufen und anschließend diese Nachrichten verarbeiten oder löschen.

Sie können versuchen, diese in ServiceBus Explorer aus:

Answer 2

Um verwaiste verzögerte Nachrichten aufgrund verlorener Sequenznummern zu verhindern, sollten Sie die Ausfallsicherheit in den Speicherprozess integrieren, in dem Sie sie verwalten, möglicherweise mit einer anderen Warteschlange. Mit anderen Worten, wenn Sie eine Nachricht verschieben, erstellen Sie eine Nachricht in einer anderen Warteschlange oder einem Zweig, um die verzögerte Sequenznummer oder die gesamte Nachricht (geklont) zu speichern.

Normalerweise verschiebe ich alle zurückgestellten Nachrichten zu meinem eigenen "latenten Thema" und handle sie getrennt. Mit anderen Worten, meine eigene Deferral-Logik, die das Problem komplett vermeidet. Wenn die automatische Zeitüberschreitungslogik in Ihrem Szenario nicht funktioniert (BrokeredMessage.TimeToLive), ist dies möglicherweise eine bessere Route für Sie.

Dieser Artikel macht einen guten Job von Ihrem Szenario teilweise zu erklären, eine besondere Überlastung von Queue.Receive mit:

http://markheath.net/post/defer-processing-azure-service-bus-message

Da Sie die Sequenznummer zu speichern (in einer elastischen Art und Weise :-)) , eine andere Alternative wäre, die gesamte Nachricht (JSON, Property Bag, usw.) zu speichern und sie erneut zu senden, wenn Sie sie erneut verarbeiten möchten (möglicherweise aus einer anderen Warteschlange).