Delen via

Service Bus-berichtenuitzondering (.NET)

  • Artikel

De Service Bus .NET-clientbibliotheek geeft uitzonderingen weer wanneer een servicebewerking of een client een fout tegenkomt. Indien mogelijk worden standaard .NET-uitzonderingstypen gebruikt om foutinformatie over te brengen. Voor scenario's die specifiek zijn voor Service Bus, wordt er een ServiceBusException gegenereerd.

De Service Bus-clients proberen automatisch uitzonderingen die als tijdelijk worden beschouwd, na de geconfigureerde opties voor opnieuw proberen. Wanneer er een uitzondering voor de toepassing wordt weergegeven, zijn alle nieuwe pogingen niet toegepast of is de uitzondering als niet-transient beschouwd. Meer informatie over het configureren van opties voor opnieuw proberen vindt u in het voorbeeld van het aanpassen van de opties voor opnieuw proberen.

ServiceBusException

De uitzondering bevat enkele contextuele informatie om u inzicht te geven in de context van de fout en de relatieve ernst.

  • EntityPath : Identificeert de Service Bus-entiteit van waaruit de uitzondering is opgetreden, indien beschikbaar.
  • IsTransient : Geeft aan of de uitzondering wel of niet als herstelbaar wordt beschouwd. In het geval dat het tijdelijk wordt geacht, heeft Azure Service Bus al het juiste beleid voor opnieuw proberen toegepast en zijn alle nieuwe pogingen mislukt.
  • Message : Bevat een beschrijving van de fout die is opgetreden en relevante context.
  • StackTrace : Vertegenwoordigt de directe frames van de aanroepstack, waarbij de locatie in de code wordt gemarkeerd waar de fout is opgetreden.
  • InnerException : Wanneer een uitzondering het resultaat was van een servicebewerking, is het vaak een exemplaar met een Microsoft.Azure.Amqp.AmqpException beschrijving van de fout, na de SPEC 1.0 (OASIS Advanced Message Queuing Protocol) 1.0.
  • Reason : Biedt een reeks bekende redenen voor de fout die helpen bij het categoriseren en verduidelijken van de hoofdoorzaak. Deze waarden zijn bedoeld om uitzonderingsfiltering en andere logica toe te passen waarbij het inspecteren van de tekst van een uitzonderingsbericht niet ideaal zou zijn. Enkele belangrijke foutredenen zijn:

    • ServiceTimeout: Geeft aan dat de Service Bus-service niet binnen de verwachte tijd heeft gereageerd op een bewerkingsaanvraag. Dit kan het gevolg zijn van een tijdelijk netwerkprobleem of serviceprobleem. De Service Bus-service heeft de aanvraag al dan niet voltooid; de status is niet bekend. In de context van de volgende beschikbare sessie geeft deze uitzondering aan dat er geen ontgrendelde sessies beschikbaar waren in de entiteit. Deze fouten zijn tijdelijke fouten die automatisch opnieuw worden geprobeerd.

    • QuotaExceeded: Geeft meestal aan dat er te veel actieve ontvangstbewerkingen zijn voor één entiteit. Om deze fout te voorkomen, vermindert u het aantal potentiële gelijktijdige ontvangsten. U kunt batch-ontvangst gebruiken om meerdere berichten per ontvangstaanvraag te ontvangen. Zie Service Bus-quota voor meer informatie.

    • MessageSizeExceeded: Geeft aan dat de berichtgrootte de maximale berichtgrootte heeft overschreden. De berichtgrootte bevat de hoofdtekst van het bericht en eventuele bijbehorende metagegevens. De beste methode voor het oplossen van deze fout is om het aantal berichten dat in een batch wordt verzonden of de grootte van de hoofdtekst in het bericht te verminderen. Omdat groottelimieten onderhevig zijn aan wijzigingen, raadpleegt u Service Bus-quota voor specifieke gegevens.

    • MessageLockLost: Geeft aan dat de vergrendeling van het bericht is verbroken. Bellers moeten proberen het bericht opnieuw te ontvangen en te verwerken. Deze uitzondering geldt alleen voor entiteiten die geen sessies gebruiken. Deze fout treedt op als de verwerking langer duurt dan de duur van de vergrendeling en de berichtvergrendeling niet wordt vernieuwd. Deze fout kan ook optreden wanneer de koppeling wordt losgekoppeld vanwege een tijdelijk netwerkprobleem of wanneer de koppeling 10 minuten inactief is.

      De Service Bus-service maakt gebruik van het AMQP-protocol, dat stateful is. Vanwege de aard van het protocol, als de koppeling die de client verbindt en de service wordt losgekoppeld nadat een bericht is ontvangen, maar voordat het bericht is opgelost, kan het bericht niet worden vereffend bij het opnieuw verbinden van de koppeling. Koppelingen kunnen worden losgekoppeld vanwege een tijdelijke netwerkfout op korte termijn, een netwerkstoring of vanwege een time-out van 10 minuten voor inactiviteit van de service. De herverbinding van de koppeling vindt automatisch plaats als onderdeel van een bewerking waarvoor de koppeling is vereist, dat wil gezegd berichten vereffenen of ontvangen. Vanwege dit gedrag kunt u te maken krijgen ServiceBusException met Reason MessageLockLost of SessionLockLost zelfs als de verlooptijd van de vergrendeling nog niet is verstreken.

    • SessionLockLost: Geeft aan dat de vergrendeling voor de sessie is verlopen. Bellers moeten proberen de sessie opnieuw te accepteren. Deze uitzondering geldt alleen voor entiteiten met sessiefunctionaliteit. Deze fout treedt op als de verwerking langer duurt dan de duur van de vergrendeling en de sessievergrendeling niet wordt vernieuwd. Deze fout kan ook optreden wanneer de koppeling wordt losgekoppeld vanwege een tijdelijk netwerkprobleem of wanneer de koppeling 10 minuten inactief is. De Service Bus-service maakt gebruik van het AMQP-protocol, dat stateful is. Vanwege de aard van het protocol, als de koppeling die de client verbindt en de service wordt losgekoppeld nadat een bericht is ontvangen, maar voordat het bericht is opgelost, kan het bericht niet worden vereffend bij het opnieuw verbinden van de koppeling. Koppelingen kunnen worden losgekoppeld vanwege een tijdelijke netwerkfout op korte termijn, een netwerkstoring of vanwege een time-out van 10 minuten voor inactiviteit van de service. De herverbinding van de koppeling vindt automatisch plaats als onderdeel van een bewerking waarvoor de koppeling is vereist, dat wil gezegd berichten vereffenen of ontvangen. Vanwege dit gedrag kunt u te maken krijgen ServiceBusException met Reason MessageLockLost of SessionLockLost zelfs als de verlooptijd van de vergrendeling nog niet is verstreken.

    • MessageNotFound: Deze fout treedt op wanneer u een uitgesteld bericht probeert te ontvangen op volgnummer voor een bericht dat niet in de entiteit bestaat of momenteel is vergrendeld.

    • SessionCannotBeLocked: Geeft aan dat de aangevraagde sessie niet kan worden vergrendeld omdat de vergrendeling al ergens anders is opgeslagen. Zodra de vergrendeling is verlopen, kan de sessie worden geaccepteerd.

    • GeneralError: Geeft aan dat er een fout is opgetreden tijdens het verwerken van de aanvraag door de Service Bus-service. Deze fout wordt vaak veroorzaakt door service-upgrades en opnieuw opstarten. Deze fouten zijn tijdelijke fouten die automatisch opnieuw worden geprobeerd.

    • ServiceCommunicationProblem: Geeft aan dat er een fout is opgetreden bij het communiceren met de service. Het probleem kan het gevolg zijn van een tijdelijk netwerkprobleem of een serviceprobleem. Deze fouten zijn tijdelijke fouten die automatisch opnieuw worden geprobeerd.

    • ServiceBusy: Geeft aan dat een aanvraag is beperkt door de service. De details die beschrijven wat ertoe kan leiden dat een aanvraag wordt beperkt en hoe u kunt voorkomen dat de beperking wordt beperkt, vindt u hier. Vertraagde aanvragen worden opnieuw geprobeerd, maar de clientbibliotheek past automatisch een 10 seconden terug uit voordat er meer aanvragen worden geprobeerd met behulp van dezelfde ServiceBusClient (of eventuele subtypen die zijn gemaakt op basis van die client). Dit kan problemen veroorzaken als de vergrendelingsduur van uw entiteit minder dan 10 seconden is, omdat bericht- of sessievergrendelingen waarschijnlijk verloren gaan voor niet-geplaatste berichten of vergrendelde sessies. Omdat vertraagde aanvragen meestal opnieuw worden geprobeerd, worden de gegenereerde uitzonderingen geregistreerd als waarschuwingen in plaats van fouten. De gebeurtenisbrongebeurtenis op specifiek waarschuwingsniveau is 43 (RunOperation heeft een uitzondering aangetroffen en het opnieuw proberen.)

    • MessagingEntityAlreadyExists: Geeft aan dat een entiteit met dezelfde naam bestaat onder dezelfde naamruimte.

    • MessagingEntityDisabled: De berichtenentiteit is uitgeschakeld. Schakel de entiteit opnieuw in met behulp van de portal.

    • MessagingEntityNotFound: De Service Bus-service kan geen Service Bus-resource vinden.

ServiceBusException verwerken - voorbeeld

Hier volgt een voorbeeld van hoe u een ServiceBusException en filtert op de Reason.

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

Andere veelvoorkomende uitzonderingen

  • ArgumentException: Client genereert deze uitzondering die wordt afgeleid van ArgumentException wanneer een parameter die is opgegeven bij interactie met de client, ongeldig is. Informatie over de specifieke parameter en de aard van het probleem vindt u in de Message.
  • InvalidOperationException: treedt op wanneer u probeert een bewerking uit te voeren die niet geldig is voor de huidige configuratie. Deze uitzondering treedt meestal op wanneer een client niet is geconfigureerd ter ondersteuning van de bewerking. Vaak kan dit worden verzacht door de opties aan te passen die aan de client worden doorgegeven.
  • NotSupportedException: treedt op wanneer een aangevraagde bewerking geldig is voor de client, maar niet wordt ondersteund door de huidige status. Informatie over het scenario vindt u in de Message.
  • AggregateException: treedt op wanneer een bewerking meerdere uitzonderingen kan tegenkomen en deze als één fout optreedt. Deze uitzondering wordt meestal aangetroffen bij het starten of stoppen van de Service Bus-processor of Service Bus-sessieprocessor.

Reden: QuotaExceeded

ServiceBusException met de reden die is ingesteld om aan te QuotaExceeded geven dat een quotum voor een specifieke entiteit is overschreden.

Notitie

Zie Quota voor Service Bus-quota.

Wachtrijen en onderwerpen

Voor wachtrijen en onderwerpen is dit vaak de grootte van de wachtrij. De eigenschap van het foutbericht bevat meer details, zoals in het volgende voorbeeld:

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

Het bericht geeft aan dat het onderwerp de groottelimiet heeft overschreden, in dit geval 1 GB (de standaardgroottelimiet).

Naamruimten

Voor naamruimten kan de uitzondering QuotaExceeded aangeven dat een toepassing het maximum aantal verbindingen met een naamruimte heeft overschreden. Voorbeeld:

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

Veelvoorkomende oorzaken

Er zijn twee veelvoorkomende oorzaken voor deze fout: de wachtrij met dode letters en niet-functionerende berichtontvangers.

  • Wachtrij met onbestelbare berichten Een lezer kan geen berichten voltooien en de berichten worden geretourneerd naar de wachtrij/het onderwerp wanneer de vergrendeling verloopt. Dit kan gebeuren als de lezer een uitzondering tegenkomt waardoor het bericht niet kan worden voltooid. Nadat een bericht 10 keer is gelezen, wordt het standaard verplaatst naar de wachtrij met dode letters. Dit gedrag wordt bepaald door de eigenschap MaxDeliveryCount en heeft een standaardwaarde van 10. Naarmate berichten zich opstapelen in de wachtrij met dode letters, nemen ze ruimte in beslag.

    Als u het probleem wilt oplossen, leest en voltooit u de berichten uit de wachtrij voor onbestelbare berichten, net zoals in een andere wachtrij.

  • Ontvanger is gestopt. Een ontvanger heeft geen berichten meer ontvangen van een wachtrij of abonnement. De manier om het probleem te identificeren, is door te kijken naar het aantal actieve berichten. Als het aantal actieve berichten hoog of toenemend is, worden de berichten niet zo snel gelezen als ze worden geschreven.

Reden: MessageLockLost

Oorzaak

ServiceBusException met de reden die is ingesteld om aan te MessageLockLost geven dat een bericht wordt ontvangen met behulp van de PeekLock-ontvangstmodus en de vergrendeling die door de client wordt bewaard, verloopt aan de servicezijde.

De vergrendeling van een bericht kan om verschillende redenen verlopen:

  • De vergrendelingstimer is verlopen voordat deze is vernieuwd door de clienttoepassing.
  • De clienttoepassing heeft de vergrendeling verkregen, opgeslagen in een permanente opslag en vervolgens opnieuw opgestart. Zodra deze opnieuw is opgestart, heeft de clienttoepassing gekeken naar de inflight-berichten en geprobeerd de berichten te voltooien.

Mogelijk ontvangt u deze uitzondering ook in de volgende scenario's:

  • Service-update
  • Update van besturingssysteem
  • Eigenschappen voor de entiteit wijzigen (wachtrij, onderwerp, abonnement) tijdens het vasthouden van de vergrendeling.

Oplossing

Wanneer een clienttoepassing MessageLockLostException ontvangt, kan het bericht niet meer worden verwerkt. De clienttoepassing kan eventueel overwegen om de uitzondering voor analyse te registreren, maar de client moet het bericht verwijderen.

Omdat de vergrendeling van het bericht is verlopen, gaat het terug naar de wachtrij (of het abonnement) en kan het worden verwerkt door de volgende clienttoepassing die oproepen ontvangt.

Als maxDeliveryCount is overschreden, wordt het bericht mogelijk verplaatst naar de DeadLetterQueue.

Reden: SessionLockLost

Oorzaak

ServiceBusException met de reden die is ingesteld MessageLockLost op wordt gegenereerd wanneer een sessie wordt geaccepteerd en de vergrendeling die door de client wordt bewaard, verloopt aan de servicezijde.

De vergrendeling van een sessie verloopt mogelijk om verschillende redenen:

  • De vergrendelingstimer is verlopen voordat deze is vernieuwd door de clienttoepassing.
  • De clienttoepassing heeft de vergrendeling verkregen, opgeslagen in een permanente opslag en vervolgens opnieuw opgestart. Zodra deze opnieuw is opgestart, heeft de clienttoepassing gekeken naar de inflight sessies en geprobeerd de berichten in die sessies te verwerken.

Mogelijk ontvangt u deze uitzondering ook in de volgende scenario's:

  • Service-update
  • Update van besturingssysteem
  • Eigenschappen voor de entiteit wijzigen (wachtrij, onderwerp, abonnement) tijdens het vasthouden van de vergrendeling.

Oplossing

Wanneer een clienttoepassing SessionLockLostException ontvangt, kunnen de berichten in de sessie niet meer worden verwerkt. De clienttoepassing kan overwegen om de uitzondering voor analyse te registreren, maar de client moet het bericht verwijderen.

Omdat de vergrendeling van de sessie is verlopen, gaat deze terug naar de wachtrij (of het abonnement) en kan deze worden vergrendeld door de volgende clienttoepassing die de sessie accepteert. Aangezien de sessievergrendeling op elk gewenst moment wordt bewaard door één clienttoepassing, wordt de verwerking in volgorde gegarandeerd.

TimeoutException

Een TimeoutException geeft aan dat een door de gebruiker geïnitieerde bewerking langer duurt dan de time-out voor de bewerking.

Controleer de waarde van de eigenschap ServicePointManager.DefaultConnectionLimit , omdat het bereiken van deze limiet ook een TimeoutException kan veroorzaken.

Time-outs kunnen optreden tijdens of tussen onderhoudsbewerkingen, zoals service-updates van Service Bus (of) besturingssysteemupdates voor resources waarop de service wordt uitgevoerd. Tijdens besturingssysteemupdates worden entiteiten verplaatst en worden knooppunten bijgewerkt of opnieuw opgestart, wat time-outs kan veroorzaken. Zie de SLA voor Service Bus voor meer informatie over de serviceovereenkomst voor de Azure Service Bus-service.

SocketException

Oorzaak

In de volgende gevallen wordt een SocketException gegenereerd:

  • Wanneer een verbindingspoging mislukt omdat de host na een opgegeven tijd niet goed heeft gereageerd (TCP-foutcode 10060).
  • Een tot stand gebrachte verbinding is mislukt omdat de verbonden host niet heeft gereageerd.
  • Er is een fout opgetreden bij het verwerken van het bericht of de time-out wordt overschreden door de externe host.
  • Probleem met onderliggende netwerkresources.

Oplossing

De SocketException-fouten geven aan dat de VM die als host fungeert voor de toepassingen, de naam <mynamespace>.servicebus.windows.net niet kan converteren naar het bijbehorende IP-adres.

Controleer of de volgende opdracht slaagt in de toewijzing aan een IP-adres.

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

Dit moet een uitvoer bieden zoals:

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

Als de bovenstaande naam niet wordt omgezet in een IP en de naamruimtealias, neemt u contact op met de netwerkbeheerder om verder te onderzoeken. Naamomzetting wordt uitgevoerd via een DNS-server, meestal een resource in het netwerk van de klant. Als de DNS-omzetting wordt uitgevoerd door Azure DNS, neemt u contact op met ondersteuning voor Azure.

Als naamomzetting werkt zoals verwacht, controleert u hier of verbindingen met Azure Service Bus zijn toegestaan.

UnauthorizedAccessException

Een UnauthorizedAccessException geeft aan dat de opgegeven referenties niet toestaan dat de aangevraagde actie wordt uitgevoerd. De Message eigenschap bevat details over de fout.

We raden u aan deze verificatiestappen te volgen, afhankelijk van het type autorisatie dat is opgegeven bij het samenstellen van de ServiceBusClient.

Uitzonderingen voor geo-replicatie

ServerBusyException

Oorzaken

  • Tijdens asynchrone replicatie (replicatievertraging groter dan nul) probeert de client een bewerking uit te voeren op een Service Bus-entiteit (wachtrij, onderwerp) of een beheerbewerking uit te voeren, maar de bewerking kan niet worden voltooid omdat de replicatievertraging tussen de primaire en de secundaire regio's de maximaal toegestane replicatievertraging in seconden heeft overschreden.
    • Voorbeeld: De bewerking wordt beperkt omdat hiermee de nieuwe replicatievertraging 38323 seconden bereikt, wat groter is dan de maximale replicatievertraging die is ingesteld (300 seconden). De huidige replicatievertraging voor de meest recente bewerking die wordt gerepliceerd, is 0 seconden.
  • De replicatiewachtrij voor een entiteit overschrijdt de maximale grootte in bytes. De maximale grootte in bytes voor een replicatiewachtrij is een interne limiet die is ingesteld door Service Bus.
    • Voorbeeld: De grootte van de replicatiewachtrij 73128000 is overschreden 67108864.
  • Bij synchrone replicatie treedt er een time-out op voor een aanvraag terwijl wordt gewacht tot een andere aanvraag moet worden gerepliceerd.
    • Voorbeeld: Grote hoeveelheid aanvragen van clienttoepassing voor skarri-stroage-exp1(westus3)/q1:MessagingJournal. Replicatie naar andere regio's wordt uitgevoerd.

Oplossing

  • De client moet weer worden uitgeschakeld om de service tijd te geven om de opgegeven workload te verwerken. Vervolgens moet de client het opnieuw proberen.

Timeout

Oorzaak

  • Een time-outuitzondering in Geo DR betekent dat de bewerking niet is voltooid binnen de door de client verstrekte time-out.
    • Bij synchrone replicatie vallen schrijf- en replicatie van een bewerking naar secundaire regio's binnen het bereik van de time-out van de bewerking.
    • Bij asynchrone replicatie valt de primaire regioschrijfbewerking van een bewerking binnen het bereik van de time-out van de bewerking, maar de replicatie van een bewerking naar secundaire regio's valt niet binnen het bereik van de time-out van de bewerking.
    • Voorbeeld: De bewerking is niet voltooid binnen de toegewezen tijd 00:01:00 voor objectbericht. (ServiceTimeout).

Oplossing

  • De client moet de bewerking opnieuw proberen.
  • Houd er rekening mee dat sommige stappen van een time-outbewerking mogelijk zijn voltooid. Het is mogelijk dat een time-outbewerking naar de primaire regio en een aantal secundaire regio's is geschreven. Als een bewerking naar de primaire regio is geschreven, wordt deze uiteindelijk gerepliceerd naar alle secundaire regio's, ongeacht de time-out van de client.

BadRequest

Oorzaak

  • Tijdens een geplande failover wordt de primaire regio tijdelijk ingesteld als alleen-lezen om ervoor te zorgen dat de secundaire regio kan inhalen. Als de client een schrijfbewerking probeert uit te voeren naar de primaire regio terwijl deze zich in deze tijdelijke status alleen-lezen bevindt, ontvangt de client een BadRequest-uitzondering.
    • Voorbeeld: De replicatierolwissel wordt uitgevoerd, de primaire replica:<entity-name> is ReadOnly.

Oplossing

  • De client moet wachten tot de geplande failover is voltooid voordat schrijfbewerkingen worden voltooid.
  • Als geplande failover te lang duurt, is het mogelijk om in plaats daarvan een geforceerde failover te activeren.

Volgende stappen

Zie de Naslaginformatie over de Azure .NET-API voor de volledige Service Bus .NET-API. Zie de gids voor probleemoplossing voor tips voor probleemoplossing.