Service Bus-meddelandefel (.NET)

Service Bus .NET-klientbiblioteket innehåller undantag när en tjänståtgärd eller en klient stöter på ett fel. När det är möjligt används standard.NET-undantagstyper för att förmedla felinformation. För scenarier som är specifika för Service Bus genereras en ServiceBusException .

Service Bus-klienterna försöker automatiskt igen undantag som anses vara tillfälliga, enligt de konfigurerade återförsöksalternativen. När ett undantag visas för programmet tillämpades antingen alla återförsök utan framgång eller så ansågs undantaget vara icke-övergående. Mer information om hur du konfigurerar omförsöksalternativ finns i exemplet Anpassa omförsöksalternativen .

ServiceBusException

Undantaget innehåller viss sammanhangsinformation som hjälper dig att förstå kontexten för felet och dess relativa allvarlighetsgrad.

• EntityPath : Identifierar den Service Bus-entitet som undantaget inträffade från, om det är tillgängligt.
• IsTransient : Anger om undantaget anses vara återställningsbart eller inte. I det fall då det ansågs vara tillfälligt har Azure Service Bus redan tillämpat rätt återförsöksprincip och alla återförsök misslyckades.
• Message : Innehåller en beskrivning av felet som inträffade och relevant kontext.
• StackTrace : Representerar de omedelbara ramarna i anropsstacken och markerar platsen i koden där felet inträffade.
• InnerException: När ett undantag var resultatet av en tjänståtgärd är det ofta en Microsoft.Azure.Amqp.AmqpException instans som beskriver felet, enligt AMQP-specifikationen (OASIS Advanced Message Queuing Protocol) 1.0.
• Reason : Innehåller en uppsättning välkända orsaker till felet som hjälper till att kategorisera och klargöra rotorsaken. Dessa värden är avsedda att tillåta tillämpning av undantagsfiltrering och annan logik där det inte är idealiskt att granska texten i ett undantagsmeddelande. Några viktiga felorsaker är:

  • ServiceTimeout: Anger att Service Bus-tjänsten inte svarade på en åtgärdsbegäran inom den förväntade tidsperioden. Det kan bero på ett tillfälligt nätverksproblem eller tjänstproblem. Service Bus-tjänsten kanske eller kanske inte har slutfört begäran. statusen är inte känd. I samband med nästa tillgängliga session anger det här undantaget att det inte fanns några olåst sessioner tillgängliga i entiteten. Dessa fel är tillfälliga fel som görs om automatiskt.

  • QuotaExceeded: Indikerar vanligtvis att det finns för många aktiva mottagningsåtgärder för en enda entitet. För att undvika det här felet kan du minska antalet potentiella samtidiga mottagningar. Du kan använda batch-mottagningar för att försöka ta emot flera meddelanden per mottagningsbegäran. Mer information finns i Service Bus-kvoter.

  • MessageSizeExceeded: Anger att meddelandestorleken överskred den maximala meddelandestorleken. Meddelandestorleken innehåller meddelandets brödtext och eventuella associerade metadata. Den bästa metoden för att lösa det här felet är att minska antalet meddelanden som skickas i en batch eller storleken på brödtexten som ingår i meddelandet. Eftersom storleksbegränsningar kan komma att ändras kan du läsa Mer information om Service Bus-kvoter .

  • MessageLockLost: Anger att låset på meddelandet går förlorat. Anropare bör försöka ta emot och bearbeta meddelandet igen. Det här undantaget gäller endast för entiteter som inte använder sessioner. Det här felet uppstår om bearbetningen tar längre tid än låsets varaktighet och meddelandelåset inte förnyas. Det här felet kan också inträffa när länken kopplas från på grund av ett tillfälligt nätverksproblem eller när länken är inaktiv i 10 minuter.

    Service Bus-tjänsten använder AMQP-protokollet, som är tillståndskänsligt. Om länken som ansluter klienten och tjänsten kopplas från efter att ett meddelande har tagits emot på grund av protokollets natur, men innan meddelandet har lösts, kan meddelandet inte lösas när länken återansluts. Länkar kan kopplas från på grund av ett kortvarigt tillfälligt nätverksfel, ett nätverksavbrott eller på grund av att tjänsten framtvingade tidsgränsen på 10 minuter för inaktivitet. Återanslutningen av länken sker automatiskt som en del av alla åtgärder som kräver länken, dvs. att lösa eller ta emot meddelanden. På grund av det här beteendet kan du stöta på ServiceBusExceptionReasonMessageLockLost eller SessionLockLost även om låsets förfallotid ännu inte har passerat.

  • SessionLockLost: Anger att låset på sessionen har upphört att gälla. Anropare bör försöka acceptera sessionen igen. Det här undantaget gäller endast för sessionsaktiverade entiteter. Det här felet uppstår om bearbetningen tar längre tid än låsets varaktighet och sessionslåset inte förnyas. Det här felet kan också inträffa när länken kopplas från på grund av ett tillfälligt nätverksproblem eller när länken är inaktiv i 10 minuter. Service Bus-tjänsten använder AMQP-protokollet, som är tillståndskänsligt. Om länken som ansluter klienten och tjänsten kopplas från efter att ett meddelande har tagits emot på grund av protokollets natur, men innan meddelandet har lösts, kan meddelandet inte lösas när länken återansluts. Länkar kan kopplas från på grund av ett kortvarigt tillfälligt nätverksfel, ett nätverksavbrott eller på grund av att tjänsten framtvingade tidsgränsen på 10 minuter för inaktivitet. Återanslutningen av länken sker automatiskt som en del av alla åtgärder som kräver länken, dvs. att lösa eller ta emot meddelanden. På grund av det här beteendet kan du stöta på ServiceBusExceptionReasonMessageLockLost eller SessionLockLost även om låsets förfallotid ännu inte har passerat.

  • MessageNotFound: Det här felet uppstår när du försöker ta emot ett uppskjutet meddelande efter sekvensnummer för ett meddelande som antingen inte finns i entiteten eller som för närvarande är låst.

  • SessionCannotBeLocked: Anger att den begärda sessionen inte kan låsas eftersom låset redan finns någon annanstans. När låset upphör att gälla kan sessionen accepteras.

  • GeneralError: Anger att Service Bus-tjänsten påträffade ett fel när begäran bearbetas. Det här felet orsakas ofta av tjänstuppgraderingar och omstarter. Dessa fel är tillfälliga fel som görs om automatiskt.

  • ServiceCommunicationProblem: Anger att det uppstod ett fel vid kommunikation med tjänsten. Problemet kan bero på ett tillfälligt nätverksproblem eller ett tjänstproblem. Dessa fel är tillfälliga fel som kommer att göras om automatiskt.

  • ServiceBusy: Anger att en begäran har begränsats av tjänsten. Information som beskriver vad som kan leda till att en begäran begränsas och hur du undviker att begränsas finns här. Begränsade begäranden görs på nytt, men klientbiblioteket tillämpar automatiskt en 10 sekunders säkerhetskopiering innan du försöker utföra fler begäranden med samma ServiceBusClient (eller eventuella undertyper som skapats från klienten). Det kan orsaka problem om entitetens låsvaraktighet är mindre än 10 sekunder, eftersom meddelande- eller sessionslås sannolikt kommer att gå förlorade för eventuella oreglerade meddelanden eller låsta sessioner. Eftersom begränsade begäranden vanligtvis görs på nytt loggas undantagen som genereras som varningar i stället för fel . Händelsen på den specifika händelsekällan på varningsnivå är 43 (RunOperation påträffade ett undantag och ett nytt försök inträffar.).

  • MessagingEntityAlreadyExists: Anger att en entitet med samma namn finns under samma namnområde.

  • MessagingEntityDisabled: Meddelandeentiteten är inaktiverad. Aktivera entiteten igen med hjälp av portalen.

  • MessagingEntityNotFound: Service Bus-tjänsten kan inte hitta en Service Bus-resurs.

Hantera ServiceBusException – exempel

Här är ett exempel på hur du hanterar en ServiceBusException och filtrerar efter Reason.

try
{
    // Receive messages using the receiver client
}
catch (ServiceBusException ex) when
    (ex.Reason == ServiceBusFailureReason.ServiceTimeout)
{
    // Take action based on a service timeout
}

Andra vanliga undantag

• ArgumentException: Klienten genererar det här undantaget från ArgumentException när en parameter som anges när interaktionen med klienten är ogiltig. Information om den specifika parametern och problemets art finns i Message.
• InvalidOperationException: Inträffar när du försöker utföra en åtgärd som inte är giltig för den aktuella konfigurationen. Det här undantaget inträffar vanligtvis när en klient inte har konfigurerats för att stödja åtgärden. Det kan ofta minimeras genom att justera de alternativ som skickas till klienten.
• NotSupportedException: Inträffar när en begärd åtgärd är giltig för klienten, men stöds inte av dess aktuella tillstånd. Information om scenariot finns i Message.
• AggregateException: Inträffar när en åtgärd kan stöta på flera undantag och visas som ett enda fel. Det här undantaget påträffas oftast när du startar eller stoppar Service Bus-processorn eller Service Bus-sessionsprocessorn.

Orsak: QuotaExceeded

ServiceBusException med orsaksuppsättningen QuotaExceeded anger att en kvot för en viss entitet har överskridits.

Kommentar

För Service Bus-kvoter, se Kvoter.

Köer och ämnen

För köer och ämnen är det ofta köns storlek. Egenskapen felmeddelande innehåller ytterligare information, som i följande exempel:

Message: The maximum entity size has been reached or exceeded for Topic: 'xxx-xxx-xxx'. 
    Size of entity in bytes:1073742326, Max entity size in bytes:
1073741824..TrackingId:xxxxxxxxxxxxxxxxxxxxxxxxxx, TimeStamp:3/15/2013 7:50:18 AM

Meddelandet anger att ämnet överskred sin storleksgräns, i det här fallet 1 GB (standardstorleksgränsen).

Namnrymder

För namnområden kan QuotaExceeded-undantaget indikera att ett program har överskridit det maximala antalet anslutningar till ett namnområde. Till exempel:

<tracking-id-guid>_G12 ---> 
System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: 
ConnectionsQuotaExceeded for namespace xxx.

Vanliga orsaker

Det finns två vanliga orsaker till det här felet: kön med obeställbara meddelanden och icke-fungerande meddelandemottagare.

• Kö med obeställbara meddelanden En läsare kan inte slutföra meddelanden och meddelandena returneras till kön/ämnet när låset upphör att gälla. Det kan inträffa om läsaren stöter på ett undantag som förhindrar att meddelandet slutförs. När ett meddelande har lästs 10 gånger flyttas det som standard till kön med obeställbara meddelanden. Det här beteendet styrs av egenskapen MaxDeliveryCount och har standardvärdet 10. När meddelanden staplas upp i kön för obeställbara meddelanden tar de upp utrymme.

  Lös problemet genom att läsa och slutföra meddelandena från kön med obeställbara meddelanden, precis som från andra köer.

• Mottagaren har stoppats. En mottagare har slutat ta emot meddelanden från en kö eller prenumeration. Sättet att identifiera problemet är att titta på antalet aktiva meddelanden. Om det aktiva antalet meddelanden är högt eller växer läss inte meddelandena lika snabbt som de skrivs.

Orsak: MessageLockLost

Orsak

ServiceBusException med orsaksinställningen MessageLockLost anger att ett meddelande tas emot med hjälp av PeekLock-mottagningsläget och att låset som innehas av klienten upphör att gälla på tjänstsidan.

Låset på ett meddelande kan upphöra att gälla på grund av olika orsaker:

• Låstimern har upphört att gälla innan den förnyades av klientprogrammet.
• Klientprogrammet hämtade låset, sparade det i ett beständigt arkiv och startade sedan om det. När den startades om tittade klientprogrammet på inflight-meddelandena och försökte slutföra meddelandena.

Du kan också få det här undantaget i följande scenarier:

• Tjänstuppdatering
• OS-uppdatering
• Ändra egenskaper för entiteten (kö, ämne, prenumeration) medan låset hålls.

Åtgärd

När ett klientprogram tar emot MessageLockLostException kan det inte längre bearbeta meddelandet. Klientprogrammet kan eventuellt överväga att logga undantaget för analys, men klienten måste ta bort meddelandet.

Eftersom låset på meddelandet har upphört att gälla går det tillbaka till kön (eller prenumerationen) och kan bearbetas av nästa klientprogram som anropar mottagningen.

Om MaxDeliveryCount har överskridits kan meddelandet flyttas till DeadLetterQueue.

Orsak: SessionLockLost

Orsak

ServiceBusException med orsak inställd MessageLockLost på genereras när en session godkänns och låset som innehas av klienten upphör att gälla på tjänstsidan.

Låset på en session kan upphöra att gälla på grund av olika orsaker:

• Låstimern har upphört att gälla innan den förnyades av klientprogrammet.
• Klientprogrammet hämtade låset, sparade det i ett beständigt arkiv och startade sedan om det. När det startades om tittade klientprogrammet på sessionerna inflight och försökte bearbeta meddelandena i dessa sessioner.

Du kan också få det här undantaget i följande scenarier:

• Tjänstuppdatering
• OS-uppdatering
• Ändra egenskaper för entiteten (kö, ämne, prenumeration) medan låset hålls.

Åtgärd

När ett klientprogram tar emot SessionLockLostException kan det inte längre bearbeta meddelandena i sessionen. Klientprogrammet kan överväga att logga undantaget för analys, men klienten måste ta bort meddelandet.

Eftersom låset på sessionen har upphört att gälla går det tillbaka till kön (eller prenumerationen) och kan låsas av nästa klientprogram som godkänner sessionen. Eftersom sessionslåset hålls av ett enskilt klientprogram vid en viss tidpunkt garanteras bearbetningen i ordning.

TimeoutException

Ett TimeoutException indikerar att en åtgärd som användaren har initierat tar längre tid än åtgärdens tidsgräns.

Du bör kontrollera värdet för egenskapen ServicePointManager.Default Anslut ionLimit, eftersom om du når den här gränsen kan det också orsaka timeoutException.

Timeouter förväntas uppstå under eller mellan olika underhållsåtgärder, till exempel tjänstuppdateringar i Service Bus (eller) operativsystemuppdateringar på resurser som kör tjänsten. Under operativsystemuppdateringar flyttas entiteter runt och noder uppdateras eller startas om, vilket kan orsaka timeout. Information om serviceavtal (SLA) för Azure Service Bus-tjänsten finns i SLA för Service Bus.

SocketException

Orsak

En SocketException genereras i följande fall:

• När ett anslutningsförsök misslyckas eftersom värden inte svarade korrekt efter en angiven tid (TCP-felkod 10060).
• En upprättad anslutning misslyckades eftersom den anslutna värden inte svarade.
• Ett fel uppstod när meddelandet bearbetades eller så överskreds tidsgränsen av fjärrvärden.
• Problem med underliggande nätverksresurser.

Åtgärd

SocketException-felen anger att den virtuella dator som är värd för programmen inte kan konvertera namnet <mynamespace>.servicebus.windows.net till motsvarande IP-adress.

Kontrollera om följande kommando lyckas mappa till en IP-adress.

PS C:\> nslookup <mynamespace>.servicebus.windows.net

Vilket bör ge utdata som:

Name:    <cloudappinstance>.cloudapp.net
Address:  XX.XX.XXX.240
Aliases:  <mynamespace>.servicebus.windows.net

Om ovanstående namn inte matchar en IP-adress och namnområdesaliaset kontrollerar du med nätverksadministratören för att undersöka saken ytterligare. Namnmatchning görs via en DNS-server, vanligtvis en resurs i kundnätverket. Om DNS-matchningen görs av Azure DNS kontaktar du Azure-supporten.

Om namnmatchningen fungerar som förväntat kontrollerar du om anslutningar till Azure Service Bus tillåts här.

UnauthorizedAccessException

En UnauthorizedAccessException anger att de angivna autentiseringsuppgifterna inte tillåter att den begärda åtgärden utförs. Egenskapen Message innehåller information om felet.

Vi rekommenderar att du följer dessa verifieringssteg, beroende på vilken typ av auktorisering som tillhandahålls när du skapar ServiceBusClient.

• Kontrollera att anslutningssträng är korrekt
• Kontrollera att SAS-token genererades korrekt
• Kontrollera att rätt rollbaserade åtkomstkontrollroller (RBAC) har beviljats

Nästa steg

Den fullständiga .NET API-referensen för Service Bus finns i Azure .NET API-referensen. Felsökningstips finns i felsökningsguiden.