Gids voor probleemoplossing voor Azure Service Bus

Dit artikel bevat tips en aanbevelingen voor het oplossen van problemen voor een aantal problemen die u ziet bij het gebruik van Azure Service Bus.

Connectiviteitsproblemen

Time-out bij het maken van verbinding met de service

Afhankelijk van de hostomgeving en het netwerk kan er een verbindingsprobleem optreden bij toepassingen als een TimeoutException, OperationCanceledExceptionof een ServiceBusException met Reason en ServiceTimeout meestal wanneer de client geen netwerkpad naar de service kan vinden.

Ga als volgt te werk om het probleem op te lossen:

• Controleer of de verbindingsreeks of volledig gekwalificeerde domeinnaam die u hebt opgegeven bij het maken van de client juist is. Zie Een Service Bus-verbindingsreeks ophalen voor meer informatie over het verkrijgen van een verbindingsreeks.
• Controleer de firewall- en poortmachtigingen in uw hostingomgeving. Controleer of de AMQP-poorten (Advanced Message Queuing Protocol) 5671 en 5672 zijn geopend en of het eindpunt is toegestaan via de firewall.
• Probeer de optie Web Socket-transport te gebruiken, die verbinding maakt met poort 443. Zie Het transport configureren voor meer informatie.
• Controleer of uw netwerk specifieke IP-adressen blokkeert. Zie voor meer informatie welke IP-adressen ik moet toestaan?
• Controleer indien van toepassing de proxyconfiguratie. Zie voor meer informatie: Het transport configureren
• Zie voor meer informatie over het oplossen van problemen met de netwerkverbinding: [Connectiviteit, certificaat of time-outproblemen][#connectivity-certificate-or-time-out-issues].

Ssl-handshakefouten (Secure Socket Layer)

Deze fout kan optreden wanneer een onderscheppingsproxy wordt gebruikt. We raden u aan om de toepassing in de hostomgeving te testen met de proxy uitgeschakeld om dit te controleren.

Socketuitputtingsfouten

Toepassingen moeten de Service Bus-typen het beste behandelen als singletons, het maken en gebruiken van één exemplaar gedurende de levensduur van de toepassing. Elke nieuwe ServiceBusClient heeft een nieuwe AMQP-verbinding gemaakt, die gebruikmaakt van een socket. Het ServiceBusClient-type beheert de verbinding voor alle typen die zijn gemaakt op basis van dat exemplaar. Elke ServiceBusReceiver, ServiceBusSessionReceiver, ServiceBusSender en ServiceBusProcessor beheert een eigen AMQP-koppeling voor de bijbehorende Service Bus-entiteit. Wanneer u ServiceBusSessionProcessor gebruikt, worden er meerdere AMQP-koppelingen tot stand gebracht, afhankelijk van het aantal sessies dat gelijktijdig wordt verwerkt.

De clients kunnen veilig in de cache worden opgeslagen wanneer ze niet actief zijn; ze zorgen voor efficiënt beheer van netwerk-, CPU- en geheugengebruik, waardoor de impact ervan tijdens perioden van inactiviteit wordt geminimaliseerd. Het is ook belangrijk dat CloseAsync of DisposeAsync wordt aangeroepen wanneer een client niet meer nodig is om ervoor te zorgen dat netwerkbronnen correct worden opgeschoond.

Onderdelen toevoegen aan de verbindingsreeks werkt niet

De huidige generatie van de Service Bus-clientbibliotheek ondersteunt alleen verbindingsreeks s in de vorm die is gepubliceerd door Azure Portal. De verbindingsreeks s zijn bedoeld om alleen basislocatie- en gedeelde sleutelgegevens te bieden. Het configureren van het gedrag van de clients wordt uitgevoerd via de bijbehorende opties.

Vorige generaties van de Service Bus-clients hebben toegestaan dat bepaalde gedragingen kunnen worden geconfigureerd door sleutel-/waardeonderdelen toe te voegen aan een verbindingsreeks. Deze onderdelen worden niet meer herkend en hebben geen effect meer op clientgedrag.

"TransportType=AmqpWebSockets" alternatief

Als u Web Sockets wilt configureren als transporttype, raadpleegt u Het transport configureren.

Alternatief voor "Authentication=Managed Identity"

Zie: Identiteits- en gedeelde toegangsreferenties voor verificatie met beheerde identiteiten. Zie Verificatie en de Azure SDK voor meer informatie over de Azure.Identity bibliotheek.

Logboekregistratie en diagnostische gegevens

De Service Bus-clientbibliotheek is volledig geïnstrueerd voor logboekregistratiegegevens op verschillende detailniveaus met behulp van .NET EventSource om informatie te verzenden. Logboekregistratie wordt uitgevoerd voor elke bewerking en volgt het patroon van het markeren van het beginpunt van de bewerking, de voltooiing ervan en eventuele uitzonderingen. Aanvullende informatie die inzicht kan bieden, wordt ook vastgelegd in de context van de bijbehorende bewerking.

Logboekregistratie inschakelen

De Service Bus-clientlogboeken zijn beschikbaar voor alle EventListener bronnen die beginnen met Azure-Messaging-ServiceBus of door te kiezen voor alle bronnen die de eigenschap AzureEventSourcehebben. Om het vastleggen van logboeken vanuit de Azure-clientbibliotheken eenvoudiger te maken, biedt de Azure.Core bibliotheek die door Service Bus wordt gebruikt een AzureEventSourceListener.

Zie voor meer informatie: Logboekregistratie met de Azure SDK voor .NET.

Gedistribueerde tracering

De Service Bus-clientbibliotheek ondersteunt gedistribueerde tracering via integratie met de Application Insights SDK. Het biedt ook experimentele ondersteuning voor de OpenTelemetry-specificatie via het .NET ActivitySource-type dat is geïntroduceerd in .NET 5. Als u ondersteuning voor gebruik met OpenTelemetry wilt inschakelen ActivitySource , raadpleegt u de ondersteuning van ActivitySource.

Als u de ondersteuning voor GA DiagnosticActivity wilt gebruiken, kunt u integreren met de Application Insights SDK. Meer informatie vindt u in ApplicationInsights met Azure Monitor.

De bibliotheek maakt de volgende reeksen:

Message
ServiceBusSender.Send
ServiceBusSender.Schedule
ServiceBusSender.Cancel
ServiceBusReceiver.Receive
ServiceBusReceiver.ReceiveDeferred
ServiceBusReceiver.Peek
ServiceBusReceiver.Abandon
ServiceBusReceiver.Complete
ServiceBusReceiver.DeadLetter
ServiceBusReceiver.Defer
ServiceBusReceiver.RenewMessageLock
ServiceBusSessionReceiver.RenewSessionLock
ServiceBusSessionReceiver.GetSessionState
ServiceBusSessionReceiver.SetSessionState
ServiceBusProcessor.ProcessMessage
ServiceBusSessionProcessor.ProcessSessionMessage
ServiceBusRuleManager.CreateRule
ServiceBusRuleManager.DeleteRule
ServiceBusRuleManager.GetRules

De meeste spanten zijn verklarend en worden gestart en gestopt tijdens de bewerking die de naam draagt. Het bereik dat de anderen met elkaar verbindt is Message. De manier waarop het bericht wordt getraceerd, is via de Diagnostic-Id eigenschap ServiceBusMessage.ApplicationProperties die door de bibliotheek is ingesteld tijdens verzend- en planningsbewerkingen. In Application Insights Message worden spanen weergegeven als een koppeling naar de verschillende andere spanten die zijn gebruikt om met het bericht te communiceren, bijvoorbeeld de ServiceBusReceiver.Receive spanwijdte, de ServiceBusSender.Send spanwijdte en de ServiceBusReceiver.Complete spanwijdte, die allemaal vanuit het Message bereik zijn gekoppeld. Hier volgt een voorbeeld van hoe dit eruitziet in Application Insights:

In de bovenstaande schermopname ziet u de end-to-end transactie die kan worden weergegeven in Application Insights in de portal. In dit scenario verzendt de toepassing berichten en gebruikt de ServiceBusSessionProcessor om ze te verwerken. De Message activiteit is gekoppeld aan ServiceBusSender.Send, ServiceBusReceiver.Receiveen ServiceBusSessionProcessor.ProcessSessionMessageServiceBusReceiver.Complete.

Notitie

Zie gedistribueerde tracering en correlatie via Service Bus-berichten voor meer informatie.

Problemen met afzenders oplossen

Kan een batch met meerdere partitiesleutels niet verzenden

Wanneer een app een batch naar een entiteit met partities verzendt, moeten alle berichten in één verzendbewerking hetzelfde PartitionKeyhebben. Als uw entiteit sessie-ingeschakeld is, geldt dezelfde vereiste voor de SessionId eigenschap. Als u berichten met verschillende PartitionKey waarden wilt SessionId verzenden, groepeert u de berichten in afzonderlijke ServiceBusMessageBatch exemplaren of neemt u ze op in afzonderlijke aanroepen naar de overbelasting sendMessagesAsync die een set ServiceBusMessage exemplaren gebruikt.

Batch kan niet worden verzonden

Een berichtenbatch bevat ServiceBusMessageBatch twee of meer berichten of een aanroep naar SendMessagesAsync waarin twee of meer berichten worden doorgegeven. De service staat niet toe dat een berichtenbatch groter is dan 1 MB. Dit gedrag is waar, ongeacht of de ondersteuningsfunctie voor grote berichten van Premium al dan niet is ingeschakeld. Als u een bericht wilt verzenden dat groter is dan 1 MB, moet het afzonderlijk worden verzonden in plaats van gegroepeerd met andere berichten. Helaas biedt het type ServiceBusMessageBatch momenteel geen ondersteuning voor het valideren dat een batch geen berichten bevat die groter zijn dan 1 MB omdat de grootte wordt beperkt door de service en kan worden gewijzigd. Dus als u van plan bent om de premium functie voor ondersteuning voor grote berichten te gebruiken, moet u ervoor zorgen dat u berichten van meer dan 1 MB afzonderlijk verzendt.

Problemen met ontvangers oplossen

Aantal geretourneerde berichten komt niet overeen met het aangevraagde aantal in batch ontvangen

Wanneer u een batch-ontvangstbewerking probeert uit te voeren, is het doorgeven van een maxMessages waarde van twee of meer aan de methode ReceiveMessagesAsync niet gegarandeerd het aantal aangevraagde berichten, zelfs als de wachtrij of het abonnement op dat moment zoveel berichten heeft en zelfs niet als het hele geconfigureerde maxWaitTime bericht nog niet is verstreken. Als u de doorvoer wilt maximaliseren en het verloop van de vergrendeling wilt voorkomen, wacht de ontvanger nog eens 20 milliseconden voor extra berichten voordat het bericht wordt verzonden voor verwerking. De maxWaitTime besturingselementen hoe lang de ontvanger wacht om het eerste bericht te ontvangen: volgende berichten worden 20 milliseconden gewacht. Daarom mag uw toepassing er niet van uitgaan dat alle beschikbare berichten in één gesprek worden ontvangen.

Bericht- of sessievergrendeling gaat verloren voordat de verlooptijd van de vergrendeling is verstreken

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. In deze situatie ontvangt u een ServiceBusException met Reason of MessageLockLost SessionLockLost zelfs als de verlooptijd van de vergrendeling nog niet is verstreken.

Door geplande of uitgestelde berichten bladeren

Geplande en uitgestelde berichten worden opgenomen wanneer u berichten bekijkt. Ze kunnen worden geïdentificeerd door de eigenschap ServiceBusReceivedMessage.State . Zodra u het SequenceNumber van een uitgesteld bericht hebt, kunt u het ontvangen met een vergrendeling via de methode ReceiveDeferredMessagesAsync .

Wanneer u met onderwerpen werkt, kunt u geplande berichten in het abonnement niet bekijken, omdat de berichten in het onderwerp blijven staan totdat de geplande wachtrijtijd is gepland. Als tijdelijke oplossing kunt u een ServiceBusReceiver maken die de onderwerpnaam doorgeeft om dergelijke berichten te bekijken. Er werken geen andere bewerkingen met de ontvanger wanneer u een onderwerpnaam gebruikt.

Door sessieberichten bladeren in alle sessies

U kunt een reguliere ServiceBusReceiver gebruiken om alle sessies te bekijken. Als u een korte weergave wilt bekijken voor een specifieke sessie, kunt u de ServiceBusSessionReceiver gebruiken, maar u moet een sessievergrendeling verkrijgen.

NotSupportedException gegenereerd bij het openen van de berichttekst

Dit probleem treedt het vaakst op in interopscenario's bij het ontvangen van een bericht dat is verzonden vanuit een andere bibliotheek die gebruikmaakt van een andere indeling voor de hoofdtekst van het AMQP-bericht. Als u met deze typen berichten werkt, raadpleegt u het voorbeeld van de hoofdtekst van het AMQP-bericht om te leren hoe u toegang krijgt tot de berichttekst.

Processorproblemen oplossen

Automatisch vernieuwen werkt niet

Automatisch vergrendelen is afhankelijk van de systeemtijd om te bepalen wanneer een vergrendeling voor een bericht of sessie moet worden vernieuwd. Als uw systeemtijd bijvoorbeeld niet juist is, is uw klok traag, kan het vernieuwen van vergrendelingen niet plaatsvinden voordat de vergrendeling verloren gaat. Zorg ervoor dat de systeemtijd juist is als automatisch vernieuwen niet werkt.

Processor lijkt vast te hangen of latentieproblemen te hebben bij het gebruik van hoge gelijktijdigheid

Dit gedrag wordt vaak veroorzaakt door thread-starvatie, met name bij het gebruik van de sessieprocessor en het gebruik van een zeer hoge waarde voor MaxConcurrentSessions, ten opzichte van het aantal kernen op de machine. Het eerste dat u moet controleren, is ervoor te zorgen dat u geen synchronisatie-over-asynchroon uitvoert in een van uw gebeurtenis-handlers. Sync-over-async is een eenvoudige manier om impasses en thread-starvatie te veroorzaken. Zelfs als u niet synchroniseert via asynchroon, kan elke pure synchronisatiecode in uw handlers bijdragen aan thread-honger. Als u hebt vastgesteld dat dit niet het probleem is, bijvoorbeeld omdat u pure asynchrone code hebt, kunt u proberen om uw [TryTimeout][TryTimeout][TryTimeout] te verhogen. Het vermindert de druk op de threadgroep door het aantal contextswitches en time-outs te verminderen die optreden bij het gebruik van de sessieprocessor in het bijzonder. De standaardwaarde voor [TryTimeout][TryTimeout] is 60 seconden, maar deze kan tot 1 uur worden ingesteld. We raden u aan om te testen met de TryTimeout set op 5 minuten als uitgangspunt en vanaf daar te herhalen. Als geen van deze suggesties werkt, hoeft u alleen maar uit te schalen naar meerdere hosts, waardoor de gelijktijdigheid in uw toepassing wordt verminderd, maar de toepassing op meerdere hosts wordt uitgevoerd om de gewenste algehele gelijktijdigheid te bereiken.

Lees verder:

• Fouten opsporen in de starvatie van threadpool
• Diagnose van .NET Core thread pool starvation met PerfView (Waarom mijn service niet alle kernen verzadiging of lijkt te staan)
• Problemen met threadpooluitputting vaststellen in .NET Core Apps (video)

Sessieprocessor duurt te lang om van sessie te wisselen

Dit kan worden geconfigureerd met behulp van [SessionIdleTimeout][SessionIdleTimeout], waarmee de processor weet hoe lang moet worden gewacht totdat een bericht van een sessie wordt ontvangen, voordat u naar een andere sessie gaat. Het is handig als u veel geparseerde sessies hebt, waarbij elke sessie slechts een paar berichten heeft. Als u verwacht dat elke sessie veel berichten bevat die indruppelen, kan het instellen ervan te laag productief zijn, omdat het onnodige sluiten van de sessie tot gevolg heeft.

Processor stopt onmiddellijk

Dit wordt vaak waargenomen voor demo- of testscenario's. StartProcessingAsync retourneert onmiddellijk nadat de processor is gestart. Als u deze methode aanroept, wordt uw toepassing niet geblokkeerd en actief gehouden terwijl de processor wordt uitgevoerd, dus u hebt een ander mechanisme nodig om dit te doen. Voor demo's of tests is het voldoende om een Console.ReadKey() aanroep toe te voegen nadat u de processor hebt gestart. Voor productiescenario's wilt u waarschijnlijk een soort frameworkintegratie zoals [BackgroundService][BackgroundService] gebruiken om handige toepassingslevenscyclushaken te bieden die kunnen worden gebruikt voor het starten en verwijderen van de processor.

Problemen met transacties oplossen

Zie [Overzicht van Service Bus-transactieverwerking][Transacties] voor algemene informatie over transacties in Service Bus.

Ondersteunde bewerkingen

Niet alle bewerkingen worden ondersteund bij het gebruik van transacties. Zie [Bewerkingen binnen een transactiebereik][TransactionOperations] voor een overzicht van de lijst met ondersteunde transacties.

Timeout

Er treedt een time-out op voor een transactie na een [periode][TransactionTimeout], dus het is belangrijk dat de verwerking binnen een transactiebereik voldoet aan deze time-out.

Bewerkingen in een transactie worden niet opnieuw geprobeerd

Dit is standaard. Houd rekening met het volgende scenario: u probeert een bericht in een transactie te voltooien, maar er is een tijdelijke fout opgetreden, bijvoorbeeld ServiceBusException met een Reason van ServiceCommunicationProblem. Stel dat de aanvraag daadwerkelijk bij de service wordt ingediend. Als de client het opnieuw zou proberen, ziet de service twee volledige aanvragen. De eerste voltooiing wordt pas voltooid nadat de transactie is doorgevoerd. De tweede voltooiing kan niet eens worden geëvalueerd voordat de eerste voltooiing is voltooid. De transactie op de client wacht totdat de voltooide bewerking is voltooid. Hiermee ontstaat een impasse waarbij de service wacht tot de client de transactie heeft voltooid, maar de client wacht totdat de service de tweede volledige bewerking bevestigt. Er treedt na 2 minuten een time-out op voor de transactie, maar dit is een slechte gebruikerservaring. Daarom proberen we bewerkingen niet opnieuw binnen een transactie.

Transacties tussen entiteiten werken niet

Als u transacties wilt uitvoeren waarbij meerdere entiteiten zijn betrokken, moet u de ServiceBusClientOptions.EnableCrossEntityTransactions eigenschap instellen op true. Zie het voorbeeld [Transacties tussen entiteiten][CrossEntityTransactions] voor meer informatie.

Targets

Informatie over Service Bus-quota vindt u [hier][ServiceBusQuotas].

Problemen met connectiviteit, certificaat of time-out

De volgende stappen helpen u bij het oplossen van problemen met connectiviteit/certificaat/time-out voor alle services onder *.servicebus.windows.net.

• Blader naar of wgethttps://<yournamespace>.servicebus.windows.net/. Het helpt bij het controleren of u problemen hebt met IP-filtering of virtueel netwerk of certificaatketen, die vaak voorkomen bij het gebruik van Java SDK.

  Een voorbeeld van een geslaagd bericht:

  <feed xmlns="http://www.w3.org/2005/Atom"><title type="text">Publicly Listed Services</title><subtitle type="text">This is the list of publicly-listed services currently available.</subtitle><id>uuid:27fcd1e2-3a99-44b1-8f1e-3e92b52f0171;id=30</id><updated>2019-12-27T13:11:47Z</updated><generator>Service Bus 1.1</generator></feed>
  

  Een voorbeeld van een foutbericht:

  <Error>
      <Code>400</Code>
      <Detail>
          Bad Request. To know more visit https://aka.ms/sbResourceMgrExceptions. . TrackingId:b786d4d1-cbaf-47a8-a3d1-be689cda2a98_G22, SystemTracker:NoSystemTracker, Timestamp:2019-12-27T13:12:40
      </Detail>
  </Error>
  

• Voer de volgende opdracht uit om te controleren of een poort is geblokkeerd op de firewall. Gebruikte poorten zijn 443 (HTTPS), 5671 en 5672 (AMQP) en 9354 (Net Messaging/SBMP). Afhankelijk van de bibliotheek die u gebruikt, worden ook andere poorten gebruikt. Hier volgt de voorbeeldopdracht die controleert of de 5671-poort is geblokkeerd. E

  tnc <yournamespacename>.servicebus.windows.net -port 5671
  

  Op Linux:

  telnet <yournamespacename>.servicebus.windows.net 5671
  

• Als er onregelmatige verbindingsproblemen zijn, voert u de volgende opdracht uit om te controleren of er verwijderde pakketten zijn. Met deze opdracht wordt geprobeerd om de 1 seconde 25 verschillende TCP-verbindingen tot stand te brengen met de service. Vervolgens kunt u controleren hoeveel van deze zijn geslaagd/mislukt en ook TCP-verbindingslatentie zien. U kunt het psping hulpprogramma hier downloaden.

  .\psping.exe -n 25 -i 1 -q <yournamespace>.servicebus.windows.net:5671 -nobanner     
  

  U kunt gelijkwaardige opdrachten gebruiken als u andere hulpprogramma's gebruikt, zoals tncping, enzovoort.

• Haal een netwerktracering op als de vorige stappen niet helpen en analyseren met behulp van hulpprogramma's zoals Wireshark. Neem indien nodig contact op met Microsoft Ondersteuning.

• Als u de juiste IP-adressen wilt vinden om toe te voegen aan de acceptatielijst voor uw verbindingen, raadpleegt u welke IP-adressen moet ik toevoegen aan de acceptatielijst.

Op 30 september 2026 wordt de ondersteuning van het SBMP-protocol voor Azure Service Bus buiten gebruik gesteld, zodat u dit protocol na 30 september 2026 niet meer kunt gebruiken. Migreer naar de nieuwste Azure Service Bus SDK-bibliotheken met behulp van het AMQP-protocol, dat essentiële beveiligingsupdates en verbeterde mogelijkheden biedt, vóór die datum.

Zie de aankondiging van de buitengebruikstelling van de ondersteuning voor meer informatie.

Problemen die kunnen optreden bij service-upgrades/opnieuw opstarten

Symptomen

• Aanvragen kunnen tijdelijk worden beperkt.
• Er kan sprake zijn van een daling van binnenkomende berichten/aanvragen.
• Het logboekbestand kan foutberichten bevatten.
• De verbinding tussen de toepassingen en de service kan enkele seconden worden verbroken.

Oorzaak

Upgrades en opnieuw opstarten van de back-endservice kunnen deze problemen in uw toepassingen veroorzaken.

Oplossing

Als de toepassingscode gebruikmaakt van SDK, is het beleid voor opnieuw proberen al ingebouwd en actief. De toepassing maakt opnieuw verbinding zonder aanzienlijke gevolgen voor de toepassing/werkstroom.

Onbevoegde toegang: Claims verzenden is vereist

Symptomen

Deze fout kan optreden wanneer u probeert toegang te krijgen tot een Service Bus-onderwerp vanuit Visual Studio op een on-premises computer met behulp van een door de gebruiker toegewezen beheerde identiteit met verzendmachtigingen.

Service Bus Error: Unauthorized access. 'Send' claim\(s\) are required to perform this operation.

Oorzaak

De identiteit heeft geen machtigingen voor toegang tot het Service Bus-onderwerp.

Oplossing

Installeer de bibliotheek Microsoft.Azure.Services.AppAuthentication om deze fout op te lossen. Zie Verificatie voor lokale ontwikkeling voor meer informatie.

Zie Een beheerde identiteit verifiëren met Microsoft Entra ID voor toegang tot Azure Service Bus-resources voor meer informatie over het toewijzen van machtigingen aan rollen.

Service Bus-uitzondering: puttoken is mislukt

Symptomen

Mogelijk wordt het volgende foutbericht weergegeven:

Microsoft.Azure.ServiceBus.ServiceBusException: Put token failed. status-code: 403, status-description: The maximum number of '1000' tokens per connection has been reached.

Op 30 september 2026 gaan we de Azure Service Bus SDK-bibliotheken WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus en com.microsoft.azure.servicebus buiten gebruik stellen, die niet voldoen aan de Azure SDK-richtlijnen. We beëindigen ook de ondersteuning van het SBMP-protocol, zodat u dit protocol na 30 september 2026 niet meer kunt gebruiken. Migreer naar de nieuwste Azure SDK-bibliotheken, die vóór die datum essentiële beveiligingsupdates en verbeterde mogelijkheden bieden.

Hoewel de oudere bibliotheken nog steeds meer dan 30 september 2026 kunnen worden gebruikt, ontvangen ze geen officiële ondersteuning en updates meer van Microsoft. Zie de aankondiging van de buitengebruikstelling van de ondersteuning voor meer informatie.

Oorzaak

Het aantal verificatietokens voor gelijktijdige koppelingen in één verbinding met een Service Bus-naamruimte heeft de limiet overschreden: 1000.

Oplossing

Ga op een van de volgende manieren te werk:

• Verminder het aantal gelijktijdige koppelingen in één verbinding of gebruik een nieuwe verbinding
• Gebruik SDK's voor Azure Service Bus, waardoor u niet in deze situatie komt (aanbevolen)

Resourcevergrendelingen werken niet wanneer u de gegevensvlak-SDK gebruikt

Symptomen

U hebt een verwijderingsvergrendeling geconfigureerd voor een Service Bus-naamruimte, maar u kunt resources verwijderen in de naamruimte (wachtrijen, onderwerpen, enzovoort) met behulp van Service Bus Explorer.

Oorzaak

Resourcevergrendeling blijft behouden in Azure Resource Manager (besturingsvlak) en verhindert niet dat de SDK-aanroep van de gegevenslaag de resource rechtstreeks uit de naamruimte verwijdert. De zelfstandige Service Bus Explorer maakt gebruik van de SDK voor het gegevensvlak, dus het verwijderen gaat door.

Oplossing

U wordt aangeraden de op Azure Resource Manager gebaseerde API te gebruiken via Azure Portal, PowerShell, CLI of Resource Manager om entiteiten te verwijderen, zodat de resourcevergrendeling voorkomt dat de resources per ongeluk worden verwijderd.

Entiteit is niet meer beschikbaar

Symptomen

Er wordt een foutbericht weergegeven dat de entiteit niet meer beschikbaar is.

Oorzaak

De resource is mogelijk verwijderd. Volg deze stappen om te bepalen waarom de entiteit is verwijderd.

• Controleer het activiteitenlogboek om te zien of er een Azure Resource Manager-aanvraag voor verwijdering is.
• Controleer het operationele logboek om te zien of er een directe API-aanroep voor verwijdering is. Zie Azure Service Bus bewaken voor meer informatie over het verzamelen van een operationeel logboek. Zie Bewerkingslogboeken voor het schema en een voorbeeld van een bewerkingslogboek
• Controleer het bewerkingslogboek om te zien of er een autodeleteonidle gerelateerde verwijdering is.

Volgende stappen

Zie de volgende artikelen:

• Azure Resource Manager-uitzonderingen. Er worden uitzonderingen vermeld die worden gegenereerd bij interactie met Azure Service Bus met behulp van Azure Resource Manager (via sjablonen of directe aanroepen).
• Berichtuitzondering. Het bevat een lijst met uitzonderingen die worden gegenereerd door .NET Framework voor Azure Service Bus.