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 tillämpade Azure Service Bus redan 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 en tidsgräns 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 passerats.

  • 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 en tidsgräns 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. Tjänsten uppgraderas och startas om orsakar ofta det här felet. 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 tjänsten begränsade begäran. 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 görs på nytt loggas undantagen som genereras som varningar i stället för fel. Den specifika händelsekällhändelsen på varningsnivå är 43 (RunOperation påträffade ett undantag och återfö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 time out
}

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 överskred 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. Egenskapen MaxDeliveryCount styr det här beteendet, som 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 slutade 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 upphörde 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 upphörde att gälla skulle det gå tillbaka till kön (eller prenumerationen) och kan bearbetas av nästa klientprogram som anropar mottagningen.

Om MaxDeliveryCount överskrids 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 upphörde att gälla innan klientprogrammet förnyade det.
• 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 upphörde att gälla skulle det gå tillbaka till kön (eller prenumerationen) och kan låsas av nästa klientprogram som accepterar sessionen. Eftersom sessionslåset hålls av ett enskilt klientprogram vid en viss tidpunkt garanteras bearbetningen i ordning.

TimeoutException

En TimeoutException anger att en användarinitierad åtgärd tar längre tid än tidsgränsen för åtgärden.

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

Tidsgränser förväntas inträffa under eller mellan underhållsåtgärder, till exempel Uppdateringar av Service Bus-tjänsten (eller) OS-uppdateringar på resurser som kör tjänsten. Under OS-uppdateringar flyttas entiteter runt och noder uppdateras eller startas om, vilket kan orsaka tidsgränser. 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å överskred fjärrvärden tidsgränsen.
• 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 namnet inte matchar en IP-adress och namnområdesaliaset kan du kontakta 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 Support.

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

Geo-replikeringsundatag

ServerBusyException

Orsaker

• Under asynkron replikering (replikeringsfördröjning större än noll) försöker klienten utföra en åtgärd på en Service Bus-entitet (kö, ämne) eller utföra en hanteringsåtgärd, men åtgärden kan inte slutföras eftersom replikeringsfördröjningen mellan de primära och sekundära regionerna överskred den maximala tillåtna replikeringsfördröjningen på några sekunder.
  • Exempel: Åtgärden begränsas eftersom med den skulle den nya replikeringsfördröjningen nå 38 323 sekunder, vilket är större än den maximala replikeringsfördröjningen som angavs (300 sekunder). Den aktuella replikeringsfördröjningen för den senaste åtgärden som replikeras är 0 sekunder.
• Replikeringskön för en entitet överskrider den maximala storleken i byte. Den maximala storleken i byte för en replikeringskö är en intern gräns som anges av Service Bus.
  • Exempel: Replikeringsköstorleken 73128000 överskred tröskelvärdet 67108864.
• Vid synkron replikering överskrider en begäran tidsgränsen i väntan på att en annan begäran ska replikeras.
  • Exempel: Stora mängder begäranden från klientprogrammet för <NAMESPACE>/<ENTITYNAME>. Replikering till andra regioner pågår.

Åtgärd

• Klienten bör backa för att ge tid för tjänsten att bearbeta sin angivna arbetsbelastning. Sedan bör klienten försöka igen.

Tidsgräns uppnådd

Orsak

• Ett timeout-undantag i Geo DR innebär att åtgärden inte slutfördes inom tidsgränsen för den angivna klienten.
  • Vid synkron replikering ligger en åtgärds primära regionskrivning och replikering till sekundära regioner inom omfånget för åtgärdens tidsgräns.
  • I asynkron replikering ligger en åtgärds primära regionskrivning inom omfånget för åtgärdens tidsgräns, men en åtgärds replikering till sekundära regioner ligger inte inom omfånget för åtgärdens tidsgräns.
  • Exempel: Åtgärden slutfördes inte inom den allokerade tiden 00:01:00 för objektmeddelande. (ServiceTimeout).

Åtgärd

• Klienten bör försöka utföra åtgärden igen.
• Vissa steg i en timeout-åtgärd kan ha slutförts. Det är möjligt att en timeout-åtgärd kan ha skrivits till den primära regionen och vissa sekundära regioner. Om en åtgärd skrevs till den primära regionen replikeras den så småningom till alla sekundära regioner oavsett tidsgräns för klienten.

BadRequest

Orsak

• Under en planerad redundansväxling anges den primära regionen tillfälligt som skrivskyddad för att den sekundära regionen ska kunna komma ikapp. Om klienten försöker skriva till den primära regionen medan den är i det här tillfälliga skrivskyddade tillståndet får klienten ett BadRequest-undantag.
  • Exempel: Replikeringsrollväxeln pågår, den primära repliken:<entitetsnamnet> är ReadOnly.

Åtgärd

• Klienten måste vänta tills den planerade redundansväxlingen har slutförts innan skrivåtgärderna lyckas.
• Om den planerade redundansväxlingen tar för lång tid kan du utlösa en tvingad redundansväxling i stället.

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.