Service Bus-meddelandefel (inaktuella)

  • Artikel

I den här artikeln visas de .NET-undantag som genereras av .NET Framework-API:er.

Den 30 september 2026 drar vi tillbaka Azure Service Bus SDK-biblioteken WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus och com.microsoft.azure.servicebus, som inte följer Riktlinjerna för Azure SDK. Vi kommer också att avsluta stödet för SBMP-protokollet, så du kommer inte längre att kunna använda det här protokollet efter den 30 september 2026. Migrera till de senaste Azure SDK-biblioteken, som erbjuder kritiska säkerhetsuppdateringar och förbättrade funktioner, före det datumet.

Även om de äldre biblioteken fortfarande kan användas efter den 30 september 2026 får de inte längre officiell support och uppdateringar från Microsoft. Mer information finns i meddelandet om supportavgång.

Undantagskategorier

Api:erna för meddelanden genererar undantag som kan ingå i följande kategorier, tillsammans med den associerade åtgärd som du kan vidta för att försöka åtgärda dem. Innebörden och orsakerna till ett undantag kan variera beroende på typen av meddelandeentitet:

  1. Användarkodfel (System.ArgumentException, System.InvalidOperationException, System.OperationCanceledException, System.Runtime.Serialization.SerializationException). Allmän åtgärd: Försök att åtgärda koden innan du fortsätter.
  2. Installations-/konfigurationsfel (Microsoft.ServiceBus.Messaging.MessagingEntityNotFoundException, System.UnauthorizedAccessException. Allmän åtgärd: Granska konfigurationen och ändra om det behövs.
  3. Tillfälliga undantag (Microsoft.ServiceBus.Messaging.MessagingException, Microsoft.ServiceBus.Messaging.ServerBusyException, Microsoft.ServiceBus.Messaging.MessagingCommunicationException). Allmän åtgärd: Försök utföra åtgärden igen eller meddela användarna. Klassen RetryPolicy i klient-SDK kan konfigureras för att hantera återförsök automatiskt. Mer information finns i Vägledning för återförsök.
  4. Andra undantag (System.Transactions.TransactionException, System.TimeoutException, Microsoft.ServiceBus.Messaging.MessageLockLostException, Microsoft.ServiceBus.Messaging.SessionLockLostException). Allmän åtgärd: specifik för undantagstypen; se tabellen i följande avsnitt:

Viktigt!

  • Azure Service Bus försöker inte utföra en åtgärd igen i händelse av ett undantag när åtgärden finns i ett transaktionsomfång.
  • Vägledning för återförsök som är specifik för Azure Service Bus finns i Återförsöksvägledning för Service Bus.

Undantagstyper

I följande tabell visas undantagstyper för meddelanden och deras orsaker samt förslag på åtgärder som du kan vidta.

Undantagstyp Beskrivning/orsak/exempel Föreslagen åtgärd Obs! Vid automatiskt/omedelbart återförsök
TimeoutException Servern svarade inte på den begärda åtgärden inom den angivna tiden, som styrs av OperationTimeout. Servern kan ha slutfört den begärda åtgärden. Det kan inträffa på grund av nätverks- eller andra infrastrukturförseningar. Kontrollera systemtillståndet för konsekvens och försök igen om det behövs. Se Timeout-undantag. Försök igen kan hjälpa i vissa fall. lägg till logik för återförsök i koden.
InvalidOperationException Den begärda användaråtgärden tillåts inte i servern eller tjänsten. Mer information finns i undantagsmeddelandet. Till exempel genererar Complete() det här undantaget om meddelandet togs emot i läget ReceiveAndDelete . Kontrollera koden och dokumentationen. Kontrollera att den begärda åtgärden är giltig. Försök igen hjälper inte.
OperationCanceledException Ett försök görs att anropa en åtgärd på ett objekt som redan har stängts, avbrutits eller tagits bort. I sällsynta fall tas den omgivande transaktionen redan bort. Kontrollera koden och se till att den inte anropar åtgärder på ett borttaget objekt. Försök igen hjälper inte.
UnauthorizedAccessException TokenProvider-objektet kunde inte hämta en token, token är ogiltig eller så innehåller token inte de anspråk som krävs för att utföra åtgärden. Kontrollera att tokenprovidern har skapats med rätt värden. Kontrollera konfigurationen av åtkomstkontrolltjänsten. Försök igen kan hjälpa i vissa fall. lägg till logik för återförsök i koden.
ArgumentException
ArgumentNullException
ArgumentOutOfRangeException		 Ett eller flera argument som anges i metoden är ogiltiga.
Den URI som anges i NamespaceManager eller Create innehåller sökvägssegment.
URI-schemat som anges till NamespaceManager eller Create är ogiltigt.
Egenskapsvärdet är större än 32 KB.		 Kontrollera anropskoden och kontrollera att argumenten är korrekta. Försök igen hjälper inte.
MessagingEntityNotFoundException Entiteten som är associerad med åtgärden finns inte eller så har den tagits bort. Kontrollera att entiteten finns. Försök igen hjälper inte.
MessageNotFoundException Försök att ta emot ett meddelande med ett visst sekvensnummer. Det här meddelandet hittades inte. Kontrollera att meddelandet inte redan har tagits emot. Kontrollera deadletter-kön för att se om meddelandet har deadlettered. Försök igen hjälper inte.
MessagingCommunicationException Klienten kan inte upprätta en anslutning till Service Bus. Kontrollera att det angivna värdnamnet är korrekt och att värden kan nås.

Om koden körs i en miljö med en brandvägg/proxy kontrollerar du att trafiken till Service Bus-domänen/IP-adressen och portarna inte blockeras.

 Ett nytt försök kan hjälpa om det uppstår tillfälliga anslutningsproblem.
ServerBusyException Tjänsten kan inte bearbeta begäran just nu. Klienten kan vänta en tid och sedan försöka utföra åtgärden igen. Klienten kan försöka igen efter ett visst intervall. Om ett nytt försök resulterar i ett annat undantag kontrollerar du återförsöksbeteendet för undantaget.
MessagingException Allmänt meddelandefel som kan genereras i följande fall:

Ett försök görs att skapa en QueueClient med ett namn eller en sökväg som tillhör en annan entitetstyp (till exempel ett ämne).

Ett försök görs att skicka ett meddelande som är större än 256 KB.

Servern eller tjänsten påträffade ett fel under bearbetningen av begäran. Mer information finns i undantagsmeddelandet. Det är vanligtvis ett tillfälligt undantag.

Begäran avslutades eftersom entiteten begränsas. Felkod: 50001, 50002, 50008.

Kontrollera koden och se till att endast serialiserbara objekt används för meddelandetexten (eller använd en anpassad serialiserare).

Kontrollera dokumentationen för de värdetyper som stöds för egenskaperna och använd endast typer som stöds.

Kontrollera egenskapen IsTransient . Om det är sant kan du försöka utföra åtgärden igen.

Om undantaget beror på begränsning väntar du några sekunder och försöker igen. Återförsöksbeteendet är odefinierat och kanske inte hjälper i andra scenarier.
MessagingEntityAlreadyExistsException Försök att skapa en entitet med ett namn som redan används av en annan entitet i tjänstnamnområdet. Ta bort den befintliga entiteten eller välj ett annat namn för den entitet som ska skapas. Försök igen hjälper inte.
QuotaExceededException Meddelandeentiteten har nått sin maximala tillåtna storlek, eller så har det maximala antalet anslutningar till ett namnområde överskridits. Skapa utrymme i entiteten genom att ta emot meddelanden från entiteten eller dess underfrågor. Se QuotaExceededException. Ett nytt försök kan hjälpa om meddelanden har tagits bort under tiden.
RuleActionException Service Bus returnerar det här undantaget om du försöker skapa en ogiltig regelåtgärd. Service Bus bifogar det här undantaget till ett meddelande med död bokstav om ett fel inträffar när regelåtgärden för meddelandet bearbetas. Kontrollera att regelåtgärden är korrekt. Försök igen hjälper inte.
FilterException Service Bus returnerar det här undantaget om du försöker skapa ett ogiltigt filter. Service Bus bifogar det här undantaget till ett deadlettered-meddelande om ett fel uppstod när filtret för meddelandet bearbetades. Kontrollera om filtret är korrekt. Försök igen hjälper inte.
SessionCannotBeLockedException Försök att acceptera en session med ett specifikt sessions-ID, men sessionen är för närvarande låst av en annan klient. Kontrollera att sessionen är upplåst av andra klienter. Ett nytt försök kan hjälpa om sessionen har släppts under tiden.
TransactionSizeExceededException För många åtgärder ingår i transaktionen. Minska antalet åtgärder som ingår i den här transaktionen. Försök igen hjälper inte.
MessagingEntityDisabledException Begäran om en körningsåtgärd på en inaktiverad entitet. Aktivera entiteten. Ett nytt försök kan hjälpa om entiteten har aktiverats under tiden.
NoMatchingSubscriptionException Service Bus returnerar det här undantaget om du skickar ett meddelande till ett ämne som har förfilter aktiverat och inget av filtren matchar. Kontrollera att minst ett filter matchar. Försök igen hjälper inte.
MessageSizeExceededException En meddelandenyttolast överskrider gränsen på 256 KB. Gränsen på 256 KB är den totala meddelandestorleken, som kan innehålla systemegenskaper och eventuella .NET-omkostnader. Minska storleken på meddelandenyttolasten och försök sedan utföra åtgärden igen. Försök igen hjälper inte.
TransactionException Den omgivande transaktionen (Transaction.Current) är ogiltig. Den kan ha slutförts eller avbrutits. Inre undantag kan ge ytterligare information. Försök igen hjälper inte.
TransactionInDoubtException En åtgärd görs på en transaktion som är osäker, eller ett försök görs att genomföra transaktionen och transaktionen blir osäker. Ditt program måste hantera det här undantaget (som ett specialfall), eftersom transaktionen kanske redan har checkats in. -

QuotaExceededException

QuotaExceededException anger att en kvot för en specifik enhet 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:

Microsoft.ServiceBus.Messaging.QuotaExceededException
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 QuotaExceededException indikera att ett program har överskridit det maximala antalet anslutningar till ett namnområde. Till exempel:

Microsoft.ServiceBus.Messaging.QuotaExceededException: ConnectionsQuotaExceeded for namespace xxx.
<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.

  1. 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 hindrar den från att anropa BrokeredMessage.Complete. 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 QueueDescription.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. Du kan använda metoden FormatDeadLetterPath för att formatera kösökvägen med obeställbara bokstäver.

  2. Mottagaren har stoppats. En mottagare har slutat ta emot meddelanden från en kö eller prenumeration. Sättet att identifiera detta är att titta på egenskapen QueueDescription.MessageCountDetails , som visar den fullständiga uppdelningen av meddelandena. Om egenskapen ActiveMessageCount är hög eller växer, läss inte meddelandena lika snabbt som de skrivs.

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.

Köer och ämnen

För köer och ämnen anges tidsgränsen antingen i MessagingFactory Inställningar. Egenskapen OperationTimeout, som en del av anslutningssträng eller via ServiceBus Anslut ionStringBuilder. Själva felmeddelandet kan variera, men det innehåller alltid det tidsgränsvärde som angetts för den aktuella åtgärden.

MessageLockLostException

Orsak

MessageLockLostException utlöses när ett meddelande tas emot med hjälp av PeekLock-mottagningsläget och 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 det startades om tittade klientprogrammet på inflight-meddelandena och försökte slutföra dessa.

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.

Upplösning

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.

SessionLockLostException

Orsak

SessionLockLostException utlöses 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.

Upplösning

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.

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.

Upplösning

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.

MessagingException

Orsak

MessagingException är ett allmänt undantag som kan genereras av olika skäl. Några av orsakerna är:

  • Ett försök görs att skapa en QueueClient för ett ämne eller en prenumeration.
  • Storleken på meddelandet som skickas är större än gränsen för den angivna nivån. Läs mer om Service Bus-kvoter och -gränser.
  • Specifika dataplansbegäran (skicka, ta emot, slutföra, överge) avbröts på grund av begränsning.
  • Tillfälliga problem orsakades av tjänstuppgraderingar och omstarter.

Kommentar

Listan över undantag ovan är inte fullständig.

Upplösning

Lösningsstegen beror på vad som orsakade att MessagingException utlöstes.

  • För tillfälliga problem (där isTransient är inställt på sant) eller för begränsningsproblem kan det lösa problemet genom att försöka utföra åtgärden igen. Standardprincipen för återförsök i SDK:t kan användas för detta.
  • För andra problem anger informationen i undantaget att problemet och lösningsstegen kan härledas från samma.

StorageQuotaExceededException

Orsak

StorageQuotaExceededException genereras när den totala storleken på entiteter i ett premiumnamnområde överskrider gränsen på 1 TB per meddelandeenhet.

Upplösning

  • Öka antalet meddelandeenheter som tilldelats premiumnamnområdet
  • Om du redan använder maximalt antal tillåtna meddelandeenheter för ett namnområde skapar du ett separat namnområde.

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.