Overzicht van wachtrijen met dead-letter van Service Bus

Azure Service Bus-wachtrijen en onderwerpabonnementen bieden een secundaire submap, een wachtrij met dode letters (DLQ). De wachtrij met onbestelbare berichten hoeft niet expliciet te worden gemaakt en kan niet worden verwijderd of onafhankelijk van de hoofdentiteit worden beheerd.

In dit artikel worden wachtrijen met dode letters in Service Bus beschreven. Veel van de discussie wordt geïllustreerd door het voorbeeld van wachtrijen voor dode letters op GitHub.

De wachtrij met dode letters

Het doel van de wachtrij met onbestelbare berichten is berichten te bewaren die niet kunnen worden bezorgd bij een ontvanger of berichten die niet kunnen worden verwerkt. Berichten kunnen vervolgens worden verwijderd uit de DLQ en geïnspecteerd. Een toepassing kan een gebruiker toestaan problemen op te lossen en het bericht opnieuw in te dienen.

Vanuit het perspectief van een API en protocol is de DLQ meestal vergelijkbaar met elke andere wachtrij, behalve dat berichten alleen kunnen worden verzonden via de bewerking voor onbestelbare letters van de bovenliggende entiteit. Bovendien wordt time-to-live niet waargenomen en kunt u een bericht van een DLQ niet doodmaken. De wachtrij met dead-letter ondersteunt volledige normale bewerkingen, zoals peek-lock delivery, receive-and-delete en transactionele bewerkingen.

De DLQ wordt niet automatisch opgeschoond. Berichten blijven in de DLQ totdat u ze expliciet ophaalt uit de DLQ en het onbestelbare bericht voltooit.

Pad naar de wachtrij met dode letters

U kunt toegang krijgen tot de wachtrij met dode letters met behulp van de volgende syntaxis:

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

In .NET kunt u de FormatDeadLetterPath methode gebruiken.

C#

QueueClient.FormatDeadLetterPath(queuePath)
SubscriptionClient.FormatDeadLetterPath(topicPath, subscriptionName)

Aantal DLQ-berichten

Het verkrijgen van het aantal berichten in de wachtrij met dode letters op onderwerpniveau is niet van toepassing omdat berichten niet op onderwerpniveau zitten. Wanneer een afzender 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 laat Service Bus Explorer zien dat er momenteel 62 berichten zijn in de DLQ voor het abonnement 'test1'.

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

Berichten verplaatsen naar de DLQ

Er zijn verschillende activiteiten in Service Bus die ertoe leiden dat berichten vanuit de berichtenengine zelf naar de DLQ worden gepusht. Een toepassing kan ook expliciet berichten naar de DLQ verplaatsen. De volgende twee eigenschappen (reden voor dode letter en beschrijving van dode letters) worden toegevoegd aan berichten met dode letters. Toepassingen kunnen hun eigen codes definiëren voor de redeneigenschap voor dode letters, maar het systeem stelt de volgende waarden in.

Reden voor dode letter	Beschrijving van fout met dode letter
HeaderSizeExceeded	Het groottequotum voor deze stream heeft de limiet overschreden.
TTLExpiredException	Het bericht is verlopen en naar de wachtrij voor onbestelbare berichten verplaatst. Zie de sectie Time to Live voor meer informatie.
Session ID is null.	Door sessie ingeschakelde entiteit staat geen berichten toe waarvan de sessie-id null is.
MaxTransferHopCountExceeded	Het maximum aantal toegestane hops bij het doorsturen tussen wachtrijen heeft de limiet overschreden. Deze waarde is ingesteld op 4.
MaxDeliveryCountExceeded	Bericht kan niet worden gebruikt na maximale bezorgingspogingen. Zie de sectie Maximum aantal bezorgingen voor meer informatie.

Time to live

Wanneer u dead-lettering inschakelt voor wachtrijen of abonnementen, worden alle verlopende berichten verplaatst naar de DLQ. De redencode voor dode letters is ingesteld op: TTLExpiredException. Uitgestelde berichten worden niet opgeschoond en verplaatst naar de wachtrij met dode letters nadat ze zijn verlopen. Dit is zo ontworpen.

Maximum aantal bezorgingen

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

Fouten tijdens het verwerken van abonnementsregels

Als u dead-lettering inschakelt voor filterevaluatieuitzonderingen, worden eventuele fouten die optreden wanneer de SQL-filterregel van een abonnement wordt uitgevoerd, samen met het offending-bericht vastgelegd in de DLQ. Gebruik deze optie niet in een productieomgeving waarin u berichttypen hebt die naar het onderwerp worden verzonden, die geen abonnees hebben, omdat dit kan leiden tot een grote belasting van DLQ-berichten. Zorg er daarom voor dat alle berichten die naar het onderwerp worden verzonden, ten minste één overeenkomend abonnement hebben.

Dead-lettering op toepassingsniveau

Naast de door het systeem geleverde functies voor dode letters kunnen toepassingen de DLQ gebruiken om onaanvaardbare berichten expliciet af te wijzen. Ze kunnen berichten bevatten die niet goed kunnen worden verwerkt vanwege een soort systeemprobleem, berichten die ongeldige nettoladingen bevatten of berichten die geen verificatie uitvoeren wanneer een beveiligingsschema op berichtniveau wordt gebruikt.

In .NET kunt u dit doen door de methode ServiceBusReceiver.DeadLetterMessageAsync aan te roepen.

We raden u aan het type uitzondering op te nemen in de DeadLetterReason en de stacktracering van de uitzondering, DeadLetterDescription omdat het eenvoudiger is om de oorzaak van het probleem op te lossen, wat resulteert in berichten met een dode letter. Houd er rekening mee dat het kan leiden tot berichten die de quotumlimiet van 256 kB voor de Standard-laag van Azure Service Bus overschrijden. U kunt uw Service Bus-naamruimte upgraden van de standard-laag naar de Premium-laag om hogere quota en limieten te hebben.

Doodletters in scenario's voor automatisch doorsturen

Berichten worden onder de volgende voorwaarden verzonden naar de wachtrij met onbestelbare berichten:

• Een bericht doorloopt meer dan vier wachtrijen of onderwerpen die aan elkaar zijn gekoppeld.
• De doelwachtrij of het doelonderwerp is uitgeschakeld of verwijderd.
• De doelwachtrij of het onderwerp overschrijdt de maximale grootte van de entiteit.

Onbestelbare brieven in verzenden via scenario's

• Als de doelwachtrij of het onderwerp is uitgeschakeld, wordt het bericht verzonden naar de wachtrij met dead letter (TDLQ) van de bronwachtrij.
• Als de doelwachtrij of entiteit de grootte van de entiteit overschrijdt, wordt het bericht verzonden naar een TDLQ van de bronwachtrij.

Onbestelbare berichten verzenden om opnieuw te worden verwerkt

Zodra u het probleem hebt opgelost waardoor het bericht is afgepakt, kunt u het opnieuw indienen bij de wachtrij of het onderwerp dat opnieuw moet worden verwerkt. In sommige gevallen, als er veel berichten in de wachtrij met dode letters staan die moeten worden verplaatst, kan code zoals deze helpen ze allemaal tegelijk te verplaatsen. Operators geven vaak de voorkeur aan een gebruikersinterface, zodat ze problemen kunnen oplossen met welke berichttypen niet kunnen worden verwerkt, van welke bronwachtrijen en om welke redenen, terwijl ze nog steeds batches berichten opnieuw kunnen indienen om opnieuw te worden verwerkt.

Beschikbare hulpmiddelen

• Met Azure Service Bus Explorer kunt u berichten handmatig verplaatsen tussen wachtrijen en onderwerpen. Hiermee kunt u de lijst met berichten bekijken en deze opnieuw verzenden om opnieuw te worden verwerkt. Deze is beschikbaar via Azure Portal, ongeacht de SDK die u gebruikt om berichten te verzenden.
• ServicePulse met NServiceBus stroomlijnt uw foutafhandeling met dit gecentraliseerde dashboard. Visualiseer, groepeer, filter- en zoekfouten snel en probeer afzonderlijke of gegroepeerde berichten efficiënt opnieuw uit te voeren. Beschikbaar voor NServiceBus-eindpunten.
• ServicePulse met MassTransit biedt een gecentraliseerd dashboard voor foutbeheer. U kunt fouten visualiseren, groeperen, filteren en zoeken met behulp van verschillende criteria. Hiermee kunt u ook afzonderlijke berichten bewerken en opnieuw proberen of groepen berichten opnieuw proberen. Beschikbaar voor MassTransit-eindpunten.

Gerelateerde inhoud

Zie Dead Lettering inschakelen voor een wachtrij of abonnement voor meer informatie over verschillende manieren om de instelling voor het verlopen van berichten te configureren.