Azure Service Bus-Messagingausnahmen (.NET)

Die Azure Service Bus-.NET-Clientbibliothek zeigt Ausnahmen an, wenn bei einem Dienstvorgang oder einem Client ein Fehler auftritt. Wenn möglich, werden standardmäßige .NET-Ausnahmetypen zum Übermitteln der Fehlerinformationen verwendet. Für Szenarien, die für Azure Service Bus spezifisch sind, wird eine Ausnahme vom Typ ServiceBusException ausgelöst.

Die Service Bus-Clients wiederholen automatisch nach den konfigurierten Wiederholungsoptionen Ausnahmen, die als vorübergehend betrachtet werden. Wenn eine Ausnahme für die Anwendung angezeigt wird, waren entweder alle Wiederholungsversuche nicht erfolgreich oder die Ausnahme wurde als nicht vorübergehend betrachtet. Weitere Informationen zum Konfigurieren von Wiederholungsoptionen finden Sie im Beispiel Anpassen der Wiederholungsoptionen.

ServiceBusException

Die Ausnahme enthält die Kontextinformationen, damit Sie den Kontext des Fehlers sowie den relativen Schweregrad verstehen können.

• EntityPath: Identifiziert die Service Bus-Entität, in der die Ausnahme aufgetreten ist, falls verfügbar.
• IsTransient: Gibt an, ob die Ausnahme als behebbar betrachtet wird. In dem Fall, in dem es als vorübergehend eingestuft wurde, hat Azure Service Bus bereits die entsprechende Wiederholungsrichtlinie angewendet, doch alle Wiederholungsversuche waren erfolglos.
• Message: Stellt eine Beschreibung des aufgetretenen Fehlers und des relevanten Kontexts bereit.
• StackTrace: Stellt die unmittelbaren Frames des Aufrufstapels dar, wobei die Position, an der der Fehler aufgetreten ist, im Code hervorgehoben wird.
• InnerException: Wenn eine Ausnahme das Ergebnis eines Dienstvorgangs war, enthält oft eine Microsoft.Azure.Amqp.AmqpException-Instanz eine Beschreibung des Fehlers entsprechend der Spezifikation OASIS Advanced Message Queuing Protocol (AMQP) 1.0.
• Reason: Gibt eine Reihe bekannter Gründe für den Fehler an, die zur Kategorisierung und Klärung der Grundursache beitragen. Diese Werte dienen dazu, die Anwendung von Ausnahmefilterung und anderer Logik zu ermöglichen, wenn die Untersuchung des Texts einer Ausnahmemeldung nicht ideal wäre. Zu wichtigen Fehlerursachen zählen unter anderem folgende:

  • ServiceTimeout: Gibt an, dass der Service Bus-Dienst nicht innerhalb des erwarteten Zeitraums auf eine Vorgangsanforderung reagiert hat. Dies kann auf ein vorübergehendes Netzwerkproblem oder Dienstproblem zurückzuführen sein. Es ist nicht bekannt, ob die Anforderung durch den Service Bus-Dienst erfolgreich abgeschlossen wurde. Diese Ausnahme gibt im Kontext der nächsten verfügbaren Sitzung an, dass keine entsperrten Sitzungen in der Entität verfügbar waren. Bei diesen Fehlern handelt es sich um vorübergehende Fehler, denen ein automatischer Wiederholungsversuch folgt.

  • QuotaExceeded: Zeigt in der Regel an, dass für eine einzelne Consumergruppe zu viele Empfangsvorgänge vorhanden sind. Um diesen Fehler zu vermeiden, verringern Sie die Anzahl potenzieller gleichzeitiger Empfangsvorgänge. Sie können Batch-Empfangsvorgänge verwenden, um zu versuchen, mehrere Nachrichten pro Empfangsanforderung zu empfangen. Weitere Informationen finden Sie unter Service Bus-Kontingente.

  • MessageSizeExceeded: Gibt an, dass die Nachrichtengröße die maximale Nachrichtengröße überschritten hat. Die Nachrichtengröße beinhaltet den Nachrichtentext und alle zugehörigen Metadaten. Der beste Ansatz zum Beheben dieses Fehlers besteht darin, die Anzahl der Nachrichten, die in einem Batch gesendet werden, oder die Größe des in der Nachricht enthaltenen Textkörpers zu reduzieren. Größenbeschränkungen können sich ggf. ändern. Detaillierte Informationen finden Sie unter Azure Service Bus-Kontingente.

  • MessageLockLost: Gibt an, dass die Sperre für die Nachricht verloren gegangen ist. Anrufer sollten versuchen, die Nachricht erneut zu empfangen und zu verarbeiten. Diese Ausnahme gilt nur für Entitäten, die keine Sitzungen verwenden. Dieser Fehler tritt auf, wenn die Verarbeitung länger dauert als die Sperrdauer und die Nachrichtensperre nicht erneuert wird. Dieser Fehler kann auch auftreten, wenn die Verbindung aufgrund eines vorübergehenden Netzwerkproblems getrennt wird oder wenn sich der Link 10 Minuten im Leerlauf befindet.

    Der Service Bus-Dienst verwendet das AMQP-Protokoll, das zustandsbehaftet ist. Es liegt in der Natur des Protokolls, dass die Nachricht bei Wiederherstellung der Verbindung nicht abgerechnet werden kann, wenn die Verbindung zwischen dem Client und dem Dienst nach dem Empfang einer Nachricht, aber vor der Abrechnung der Nachricht getrennt wird. Verbindungen können aufgrund eines kurzfristigen vorübergehenden Netzwerkfehlers, eines Netzwerkausfalls oder aufgrund des vom Dienst erzwungenen Leerlauftimeouts von 10 Minuten getrennt werden. Die Wiederherstellung der Verbindung erfolgt automatisch bei jedem Vorgang, für den die Verbindung benötigt wird, d. h. beim Abrechnen oder Empfangen von Nachrichten. Aufgrund dieses Verhaltens treten möglicherweise ServiceBusException mit dem Reason-Wert MessageLockLost oder SessionLockLost auf, auch wenn die Ablaufzeit der Sperre noch nicht verstrichen ist.

  • SessionLockLost: Gibt an, dass die Sperre für die Sitzung abgelaufen ist. Anrufer sollten versuchen, die Sitzung erneut zu akzeptieren. Diese Ausnahme gilt nur für sitzungsfähige Entitäten. Dieser Fehler tritt auf, wenn die Verarbeitung länger dauert als die Sperrdauer und die Sitzungssperre nicht erneuert wird. Dieser Fehler kann auch auftreten, wenn die Verbindung aufgrund eines vorübergehenden Netzwerkproblems getrennt wird oder wenn sich der Link 10 Minuten im Leerlauf befindet. Der Service Bus-Dienst verwendet das AMQP-Protokoll, das zustandsbehaftet ist. Es liegt in der Natur des Protokolls, dass die Nachricht bei Wiederherstellung der Verbindung nicht abgerechnet werden kann, wenn die Verbindung zwischen dem Client und dem Dienst nach dem Empfang einer Nachricht, aber vor der Abrechnung der Nachricht getrennt wird. Verbindungen können aufgrund eines kurzfristigen vorübergehenden Netzwerkfehlers, eines Netzwerkausfalls oder aufgrund des vom Dienst erzwungenen Leerlauftimeouts von 10 Minuten getrennt werden. Die Wiederherstellung der Verbindung erfolgt automatisch bei jedem Vorgang, für den die Verbindung benötigt wird, d. h. beim Abrechnen oder Empfangen von Nachrichten. Aufgrund dieses Verhaltens treten möglicherweise ServiceBusException mit dem Reason-Wert MessageLockLost oder SessionLockLost auf, auch wenn die Ablaufzeit der Sperre noch nicht verstrichen ist.

  • MessageNotFound: Dieser Fehler tritt auf, wenn versucht wird, eine verzögerte Nachricht nach der Sequenznummer einer Nachricht zu empfangen, die entweder nicht in der Entität vorhanden ist oder momentan gesperrt ist.

  • SessionCannotBeLocked: Gibt an, dass die angeforderte Sitzung nicht gesperrt werden kann, da die Sperre bereits an anderer Stelle gehalten wird. Sobald die Sperre abläuft, kann die Sitzung akzeptiert werden.

  • GeneralError: Gibt an, dass beim Verarbeiten der Anforderung ein Fehler beim Service Bus-Dienst aufgetreten ist. Dieser Fehler wird häufig durch Dienstupgrades und Neustarts verursacht. Bei diesen Fehlern handelt es sich um vorübergehende Fehler, denen ein automatischer Wiederholungsversuch folgt.

  • ServiceCommunicationProblem: Gibt an, dass ein Fehler in der Kommunikation mit dem Dienst aufgetreten ist. Das Problem kann aus einem vorübergehenden Netzwerkproblem oder einem Dienstproblem resultieren. Diese Fehlern sind vorübergehende Fehler, denen ein automatischer Wiederholungsversuch folgt.

  • ServiceBusy: Gibt an, dass die Anforderung durch den Dienst gedrosselt wurde. Eine Beschreibung der Umstände, die zu einer Drosselung der Anforderung führen können, und der Art und Weise, wie sich eine Drosselung vermeiden lässt, finden Sie hier. Gedrosselte Anforderungen werden wiederholt, aber die Clientbibliothek wendet automatisch eine Pause von 10 Sekunde an, bevor weitere Anforderungen mit demselben ServiceBusClient (oder mit von diesem Client erstellten Untertypen) versucht werden. Das kann zu Problemen führen, wenn die Sperrdauer einer Entität weniger als 10 Sekunden beträgt, da Nachrichten- oder Sitzungssperren für ausstehende Nachrichten oder gesperrte Sitzungen wahrscheinlich verloren gehen. Da gedrosselte Anforderungen im Allgemeinen erfolgreich wiederholt werden, werden die generierten Ausnahmen als Warnungen und nicht als Fehler protokolliert. Das spezifische Ereignisquellenereignis auf Warnungsebene ist 43 (RunOperation hat eine Ausnahme festgestellt, und es tritt ein Wiederholungsversuch auf).

  • MessagingEntityAlreadyExists: Gibt an, dass eine Entität mit demselben Namen im demselben Namespace vorhanden ist.

  • MessagingEntityDisabled: Die Messaging-Entität ist deaktiviert. Aktivieren Sie die Entität mithilfe des Portals erneut.

  • MessagingEntityNotFound: Service Bus-Dienst kann eine Service Bus-Ressource nicht finden.

Behandeln von ServiceBusException – Beispiel

Im folgenden Beispiel wird gezeigt, wie Sie eine Ausnahme vom Typ ServiceBusException behandeln und nach Reason filtern.

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

Andere allgemeine Ausnahmen

• ArgumentException: Der Client löst diese Ausnahme aus, die von ArgumentException abgeleitet ist, wenn ein Parameter bei der Interaktion mit dem Client ungültig ist. Informationen über den spezifischen Parameter und die Art des Problems finden Sie in der Message-Instanz.
• InvalidOperationException: Tritt auf, wenn versucht wird, einen Vorgang auszuführen, der in der aktuelle Konfiguration unzulässig ist. Diese Ausnahme tritt in der Regel auf, wenn ein Client so konfiguriert wurde, dass er den Vorgang nicht unterstützt. Häufig lässt sich dies korrigieren, indem die an den Client übergebenen Optionen angepasst werden.
• NotSupportedException: Tritt auf, wenn ein angeforderter Vorgang für den Client zulässig ist, aber nicht von dessen aktuellem Zustand unterstützt wird. Informationen zum Szenario finden Sie in der Message-Instanz.
• AggregateException: Tritt auf, wenn bei einem Vorgang mehrere Ausnahmen auftreten und diese als einzelner Fehler angezeigt werden. Diese Ausnahme tritt am häufigsten beim Starten oder Beenden des Service Bus-Prozessors oder des Service Bus-Sitzungsprozessors auf.

Grund: QuotaExceeded

Eine Ausnahme vom Typ ServiceBusException mit dem Grund QuotaExceeded gibt an, dass das Kontingent für eine bestimmte Entität überschritten wurde.

Hinweis

Informationen zu Service Bus-Kontingenten finden Sie unter Kontingente.

Warteschlangen und Themen

Für Warteschlangen und Themen ist dies häufig die Größe der Warteschlange. Die Fehlermeldungseigenschaft enthält weitere Details, wie das folgende Beispiel zeigt:

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

Die Meldung besagt, dass das Thema seine maximale Größe überschritten hat, in diesem Fall 1GB (Standardgrenzwert).

Namespaces

Bei Namespaces kann eine QuotaExceeded-Ausnahme darauf hinweisen, dass eine Anwendung die maximale Anzahl der Verbindungen zu einem Namespace überschritten hat. Beispiel:

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

Häufige Ursachen

Für diesen Fehler gibt es zwei häufige Ursachen: die Warteschlange für unzustellbare Nachrichten und nicht funktionierende Nachrichtenempfänger.

• Warteschlange für unzustellbare Nachrichten : Ein Leser kann Nachrichten nicht abschließen, und die Nachrichten werden nach Ablauf der Sperre an die Warteschlange/das Thema zurückgegeben. Dies kann auftreten, wenn beim Leser eine Ausnahme auftritt, die den Abschluss der Nachricht verhindert. Nachdem eine Nachricht 10 Mal gelesen wurde, wird sie standardmäßig in die Warteschlange für unzustellbare Nachrichten verschoben. Dieses Verhalten wird von der Eigenschaft MaxDeliveryCount gesteuert, die den Standardwert 10 hat. Wenn sich Nachrichten in der Warteschlange für unzustellbare Nachrichten anhäufen, belegen sie Speicherplatz.

  Um das Problem zu beheben, lesen und schließen Sie die Nachrichten in der Warteschlange für unzustellbare Nachrichten ab – genau wie in jeder anderen Warteschlange.

• Empfänger beendet. Ein Empfänger hat den Empfang von Nachrichten aus einer Warteschlange oder einem Abonnement beendet. Das Problem lässt sich am besten identifizieren, indem Sie die Anzahl der aktiven Nachrichten betrachten. Wenn die Anzahl der aktiven Nachrichten hoch ist oder wächst, werden die Nachrichten nicht so schnell gelesen, wie sie geschrieben werden können.

Grund: MessageLockLost

Ursache

Die Ausnahme ServiceBusException mit dem Grund MessageLockLost wird ausgelöst, wenn eine Nachricht über den Empfangsmodus PeekLock empfangen wird und die Sperre des Clients auf Dienstseite abgelaufen ist.

Die Sperre einer Nachricht kann aus verschiedenen Gründen ablaufen:

• Der Timer der Sperre ist abgelaufen, bevor die Clientanwendung ihn erneuert hat.
• Die Clientanwendung hat die Sperre abgerufen, diese in einem dauerhaften Speicher gespeichert und dann neu gestartet. Nach dem Neustart hat die Clientanwendung die In-Flight-Nachrichten abgerufen und versucht, diese abzuschließen.

Möglicherweise tritt diese Ausnahme auch in den folgenden Szenarien auf:

• Dienstupdate
• Betriebssystemupdate
• Ändern von Eigenschaften für die Entität (Warteschlange, Thema, Abonnement) während Aufrechterhaltung der Sperre.

Lösung

Wenn die Clientanwendung die Ausnahme MessageLockLostException empfängt, kann sie die Nachrichten nicht mehr verarbeiten. Die Clientanwendung könnte die Ausnahme optional zu Analysezwecken protokollieren, jedoch muss der Client die Nachricht verwerfen.

Da die Sperre der Nachricht abgelaufen ist, wird sie wieder in die Warteschlange (oder das Abonnement) eingereiht, sodass sie von der nächsten Clientanwendung verarbeiten werden kann, die einen Empfangsaufruf sendet.

Wenn MaxDeliveryCount überschritten wurde, kann die Nachricht in die Warteschlange DeadLetterQueue verschoben werden.

Grund: SessionLockLost

Ursache

Die Ausnahme ServiceBusException mit dem Grund MessageLockLost wird ausgelöst, wenn eine Sitzung akzeptiert wird und die Sperre des Clients auf Dienstseite abläuft.

Die Sperre einer Sitzung kann aus verschiedenen Gründen ablaufen:

• Der Timer der Sperre ist abgelaufen, bevor die Clientanwendung ihn erneuert hat.
• Die Clientanwendung hat die Sperre abgerufen, diese in einem dauerhaften Speicher gespeichert und dann neu gestartet. Nach diesem Neustart hat die Clientanwendung die In-Flight-Sitzungen abgerufen und versucht, die Nachrichten in diesen Sitzungen abzuschließen.

Möglicherweise wird diese Ausnahme auch in den folgenden Szenarios ausgelöst:

• Dienstupdate
• Betriebssystemupdate
• Ändern von Eigenschaften für die Entität (Warteschlange, Thema, Abonnement) während Aufrechterhaltung der Sperre.

Lösung

Wenn die Clientanwendung die Ausnahme SessionLockLostException empfängt, kann sie die Nachrichten in der Sitzung nicht mehr verarbeiten. Die Clientanwendung kann die Ausnahme zu Analysezwecken protokollieren, jedoch muss der Client die Nachricht verwerfen.

Da die Sperre der Sitzung abgelaufen ist, wird sie wieder in die Warteschlange (oder das Abonnement) eingereiht, sodass sie von der nächsten Clientanwendung, die die Sitzung akzeptiert, gesperrt werden kann. Da die Sitzungssperre immer von jeweils einer einzelnen Clientanwendung aufrechterhalten wird, wird die Reihenfolge der Verarbeitung garantiert.

TimeoutException

Eine TimeoutException zeigt an, dass ein von einem Benutzer initiierter Vorgang länger als das Timeout des Vorgangs dauert.

Überprüfen Sie den Wert der ServicePointManager.DefaultConnectionLimit-Eigenschaft, da das Erreichen dieses Limits auch eine TimeoutException auslösen kann.

Es wird erwartet, dass es während oder zwischen Wartungsarbeiten, z. B. bei Service Bus-Dienstupdates (oder) Betriebssystemaktualisierungen für Ressourcen, die den Dienst ausführen, zu Timeouts kommt. Bei Betriebssystemupdates werden Entitäten verschoben, und Knoten werden aktualisiert oder neu gestartet. Dies kann zu Timeouts führen. Details zur Vereinbarung zum Service Level (SLA) für den Azure Service Bus-Dienst finden Sie unter SLA für Service Bus.

SocketException

Ursache

In den folgenden Fällen wird eine SocketException-Ausnahme ausgelöst:

• Wenn ein Verbindungsversuch fehlschlägt, weil der Host nach einem festgelegten Zeitraum nicht ordnungsgemäß reagiert hat (TCP-Fehlercode 10060)
• Eine aktive Verbindung ist fehlgeschlagen, weil der verbundene Host nicht reagiert hat.
• Ein Fehler ist beim Verarbeiten der Nachricht aufgetreten, oder es kam beim Remotehost zu einer Zeitüberschreitung.
• Es liegt ein Problem mit der zugrunde liegenden Netzwerkressource vor.

Lösung

Die SocketException-Fehler geben an, dass die VM, die die Anwendungen hostet, den Namen <mynamespace>.servicebus.windows.net nicht in die entsprechende IP-Adresse konvertieren kann.

Überprüfen Sie, ob der folgende Befehl erfolgreich eine IP-Adresse zuweisen kann.

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

Dadurch sollte eine Ausgabe ähnlich der folgenden zurückgegeben werden:

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

Wenn der obige Name nicht in eine IP-Adresse und den Namespace-Alias aufgelöst wird, wenden Sie sich zur weiteren Untersuchung an den oder die Netzwerkadministrator*in. Die Namensauflösung erfolgt über einen DNS-Server. Diese Ressource befindet sich üblicherweise im Kundennetzwerk. Wenn die DNS-Auflösung über Azure DNS erfolgt, wenden Sie sich an den Azure-Support.

Wenn die Namensauflösung erwartungsgemäß funktioniert, überprüfen Sie hier, ob Verbindungen zu Azure Service Bus zugelassen werden.

UnauthorizedAccessException

Eine UnauthorizedAccessException gibt an, dass die bereitgestellten Anmeldeinformationen nicht zulassen, dass die angeforderte Aktion ausgeführt werden kann. Die Eigenschaft „Message“ enthält Details zum Fehler.

Es wird empfohlen, diese Überprüfungsschritte abhängig von der Art der Autorisierung zu befolgen, die beim Erstellen von „ServiceBusClient“ bereitgestellt wird.

• Vergewissern Sie sich, dass die Verbindungszeichenfolge richtig ist.
• Vergewissern Sie sich, dass das SAS-Token ordnungsgemäß generiert wurde.
• Vergewissern Sie sich, dass die richtigen rollenbasierten Zugriffssteuerungsrollen (RBAC) erteilt wurden.

Ausnahmen bei der Georeplikation

ServerBusyException

Ursachen

• Während der asynchronen Replikation (Verzögerung bei der Replikation größer als Null) versucht der Client, einen Vorgang für eine Service Bus-Entität (Warteschlange, Thema) oder einen Verwaltungsvorgang auszuführen. Der Vorgang kann jedoch nicht abgeschlossen werden, da die Replikationsverzögerung zwischen den primären und sekundären Regionen die maximale zulässige Verzögerung in Sekunden überschritten hat.
  • Beispiel: Der Vorgang wird gedrosselt, da die neue Replikationsverzögerung 38.323 Sekunden erreichen würde. Dies liegt über der festgelegten maximalen Verzögerung (300 Sekunden). Die aktuelle Verzögerung für die Replikation beim neuesten Replikationsvorgang beträgt 0 Sekunden.
• Die Replikationswarteschlange für eine Entität überschreitet die maximale Größe in Byte. Die maximale Größe in Byte für eine Replikationswarteschlange ist ein intern von Service Bus festgelegter Grenzwert.
  • Beispiel: Die Replikationswarteschlangengröße 73.128.000 hat den Schwellenwert 67.108.864 überschritten.
• Bei der synchronen Replikation tritt beim Warten auf eine zu replizierende Anforderung eine Anforderungszeitüberschreitung auf.
  • Beispiel: Hohe Anzahl von Anforderungen von der Clientanwendung für skarri-stroage-exp1(westus3)/q1:MessagingJournal. Die Replikation in andere Regionen wird ausgeführt.

Lösung

• Der Client sollte pausiert werden, um dem Dienst Zeit für die Verarbeitung der Workload zu geben. Danach sollte der Client den Vorgang wiederholen.

Timeout

Ursache

• Eine Zeitüberschreitungsausnahme bei der georedundanten Notfallwiederherstellung bedeutet, dass der Vorgang nicht innerhalb des vom Client bestimmten Zeitlimits abgeschlossen wurde.
  • Bei der synchronen Replikation liegt das Schreiben eines Vorgangs in der primären Region und die Replikation in sekundäre Regionen im Bereich des Vorgangszeitlimits.
  • Bei der asynchronen Replikation liegt das Schreiben eines Vorgangs in der primären Region im Bereich des Vorgangszeitlimits, aber die Replikation in sekundäre Regionen nicht.
  • Beispiel: Der Vorgang wurde nicht innerhalb der zugewiesenen Zeit von 00:01:00 für die Objektnachricht abgeschlossen. (ServiceTimeout)

Lösung

• Der Client sollte den Vorgang wiederholen.
• Beachten Sie, dass einige Schritte eines Vorgangs, der das Zeitlimit überschritten hat, möglicherweise abgeschlossen wurden. Es ist möglich, dass ein solcher Vorgang in die primäre Region und einige sekundäre Regionen geschrieben wurde. Wenn ein Vorgang in die primäre Region geschrieben wurde, wird er letztendlich unabhängig von der Zeitüberschreitung des Clients in alle sekundären Regionen repliziert.

BadRequest

Ursache

• Während eines geplanten Failovers wird die primäre Region vorübergehend als schreibgeschützt festgelegt, damit die sekundäre Region aufholen kann. Wenn der Client während dieses temporären schreibgeschützten Zustands versucht, in die primäre Region zu schreiben, erhält er eine BadRequest-Ausnahme.
  • Beispiel: Der Wechsel der Replikationsrolle findet gerade statt, das primäre Replikat:<Entitätsname> ist ReadOnly.

Lösung

• Der Client muss warten, bis das geplante Failover abgeschlossen ist, bevor Schreibvorgänge erfolgreich ausgeführt werden können.
• Falls das geplante Failover zu lange dauert, kann stattdessen ein Failover erzwungen werden.

Nächste Schritte

Die vollständige .NET-API-Referenz für Service Bus finden Sie unter Azure .NET API Referenz. Weitere Informationen zur Problembehandlung finden Sie im Leitfaden zur Problembehandlung.