Overzicht van Service Bus wachtrijen voor niet-lees berichten

Azure Service Bus wachtrijen en onderwerpabonnementen bieden een secundaire subqueue, ook wel een wachtrij voor inlopende letters (DLQ) genoemd. De wachtrij voor in wachtrijen geplaatste berichten hoeft niet expliciet te worden gemaakt en kan niet worden verwijderd of beheerd, onafhankelijk van de hoofdentiteit.

In dit artikel worden wachtrijen in wachtrijen met inlopende Service Bus. Een groot deel van de discussie wordt geïllustreerd door het voorbeeld van wachtrijen met in wachtrijen GitHub.

De wachtrij voor in wachtrij met in wachtrij geplaatste berichten

Het doel van de wachtrij voor niet-bezorgde berichten is om berichten te houden die niet aan een ontvanger kunnen worden geleverd of berichten die niet kunnen worden verwerkt. Berichten kunnen vervolgens worden verwijderd uit de DLQ en worden geïnspecteerd. Een toepassing kan, met behulp van een operator, problemen corrigeren en het bericht opnieuw indienen, het feit melden dat er een fout is opgetreden en corrigerende actie ondernemen.

Vanuit het perspectief van een API en protocol is de DLQ voornamelijk vergelijkbaar met elke andere wachtrij, behalve dat berichten alleen kunnen worden verzonden via de dead-letter-bewerking van de bovenliggende entiteit. Bovendien wordt time-to-live niet waargenomen en kunt u een bericht van een DLQ niet in een dead-letter schrijven. De wachtrij voor niet-bezorgde berichten biedt volledige ondersteuning voor levering van peek-lock en transactionele bewerkingen.

Er is geen automatische opschoning van de DLQ. Berichten blijven in de DLQ totdat u ze expliciet uit de DLQ op haalt en het bericht over de inlopende berichten voltooit.

Aantal DLQ-berichten

Het is niet mogelijk om het aantal berichten in de wachtrij voor berichten in de wachtrij voor berichten te verkrijgen op onderwerpniveau. Dat komt doordat berichten niet op het niveau van het onderwerp zitten, tenzij Service Bus een interne fout veroorzaakt. Wanneer een afzender in plaats daarvan een bericht naar een onderwerp verzendt, wordt het bericht binnen milliseconden doorgestuurd naar abonnementen voor het onderwerp en bevindt het zich dus niet meer op onderwerpniveau. U kunt dus berichten zien in de DLQ die is gekoppeld aan het abonnement voor het onderwerp. In het volgende voorbeeld ziet Service Bus Explorer dat de DLQ momenteel 62 berichten bevat voor het abonnement test1.

U kunt ook het aantal DLQ-berichten krijgen met behulp van de Azure CLI-opdracht: az servicebus topic subscription show .

Berichten verplaatsen naar de DLQ

Er zijn verschillende activiteiten in Service Bus ervoor zorgen dat berichten naar de DLQ worden pushen vanuit de berichten-engine zelf. Een toepassing kan ook expliciet berichten naar de DLQ verplaatsen. De volgende twee eigenschappen (dead-letter reason en dead-letter description) worden toegevoegd aan berichten met een dead-letter. Toepassingen kunnen hun eigen codes definiëren voor de eigenschap dead-letter reason, maar het systeem stelt de volgende waarden in.

Maximum aantal leveringen

Er is een limiet voor het aantal pogingen om berichten te leveren voor Service Bus wachtrijen en abonnementen. De standaardwaarde is 10. Wanneer een bericht is afgeleverd onder een peek-lock, maar expliciet is verlaten of de vergrendeling is verlopen, wordt het aantal leveringen voor het bericht verhoogd. Wanneer het aantal leveringen de limiet overschrijdt, wordt het bericht verplaatst naar de DLQ. De reden van de onbewerkte brief voor het bericht in DLQ is ingesteld op: MaxDeliveryCountExceeded. Dit gedrag kan niet worden uitgeschakeld, maar u kunt het maximum aantal leveringen instellen op een groot aantal.

Time To Live

Wanneer u in wachtrijen of abonnementen dead-lettering inschakelen, worden alle verlopen berichten verplaatst naar de DLQ. De redencode voor de dead-letter is ingesteld op: TTLExpiredException.

De uitgestelde berichten worden ook niet verwijderd en na het verlopen naar de wachtrij voor niet-leesberichten verplaatst. Dit gedrag is standaard.

Fouten tijdens het verwerken van abonnementsregels

Als u dead-lettering inschakelen voor filterevaluatie-uitzonderingen, worden eventuele fouten die optreden tijdens het uitvoeren van de SQL-filterregel van een abonnement vastgelegd in de DLQ, samen met het beledigende bericht. Gebruik deze optie niet in een productieomgeving waarin niet alle berichttypen abonnees hebben.

Dead lettering op toepassingsniveau

Naast de systeemfuncties voor dead-lettering kunnen toepassingen de DLQ gebruiken om onacceptabele berichten expliciet af te wijzen. Ze kunnen berichten bevatten die niet goed kunnen worden verwerkt vanwege een soort systeemprobleem, berichten die verkeerd vorm geven nettoladingen bevatten of berichten die niet kunnen worden verificatie wanneer een beveiligingsschema op berichtniveau wordt gebruikt.

Dead-lettering in ForwardTo- of SendVia-scenario's

Berichten worden onder de volgende voorwaarden verzonden naar de wachtrij voor in een wachtrij voor niet-voltooide overdrachten:

• Een bericht doorstaat meer dan vier wachtrijen of onderwerpen die aan elkaar zijn vastgeketend.
• De doelwachtrij of het doelonderwerp is uitgeschakeld of verwijderd.
• De doelwachtrij of het doelonderwerp overschrijdt de maximale entiteitsgrootte.

Pad naar de wachtrij voor inlopende berichten

U kunt toegang krijgen tot de wachtrij voor in wachtrijen met de volgende syntaxis:

<queue path>/$deadletterqueue
<topic path>/Subscriptions/<subscription path>/$deadletterqueue

Volgende stappen

Zie Enable dead lettering for a queue or subscription (Inschakelen voor inlopende berichten voor een wachtrij of abonnement) voor meer informatie over verschillende manieren om de instelling voor het verlopen van berichten te configureren.