Udostępnij za pośrednictwem

Wyjątki obsługi komunikatów usługi Service Bus (.NET)

  • Artykuł

Biblioteka klienta .NET usługi Service Bus wyświetla wyjątki, gdy operacja usługi lub klient napotka błąd. Jeśli to możliwe, standardowe typy wyjątków platformy .NET są używane do przekazywania informacji o błędach. W przypadku scenariuszy specyficznych dla usługi Service Bus zgłaszany jest wyjątek ServiceBusException .

Klienci usługi Service Bus automatycznie ponawiają próby wyjątków, które są uznawane za przejściowe, zgodnie ze skonfigurowanymi opcjami ponawiania prób. W przypadku wystąpienia wyjątku w aplikacji wszystkie ponowne próby zostały zastosowane bezskutecznie lub wyjątek został uznany za nieprzejrzysty. Więcej informacji na temat konfigurowania opcji ponawiania można znaleźć w przykładzie Dostosowywanie opcji ponawiania prób.

ServiceBusException

Wyjątek zawiera pewne informacje kontekstowe ułatwiające zrozumienie kontekstu błędu i jego względnej ważności.

  • EntityPath : określa jednostkę usługi Service Bus, z której wystąpił wyjątek, jeśli jest dostępny.
  • IsTransient : wskazuje, czy wyjątek jest uznawany za możliwy do odzyskania. W przypadku, gdy został uznany za przejściowy, usługa Azure Service Bus zastosowała już odpowiednie zasady ponawiania prób, a wszystkie próby nie powiodły się.
  • Message : zawiera opis błędu, który wystąpił i odpowiedni kontekst.
  • StackTrace : reprezentuje bezpośrednie ramki stosu wywołań, wyróżniając lokalizację w kodzie, w którym wystąpił błąd.
  • InnerException: Gdy wyjątek był wynikiem operacji usługi, często jest to wystąpienie opisujące błąd, zgodnie z specyfikacją Microsoft.Azure.Amqp.AmqpExceptionPROTOKOŁU ADVANCED Message Queuing Protocol (AMQP) 1.0 o nazwie OASIS Advanced Message Queuing Protocol (AMQP).
  • Reason : Zawiera zestaw dobrze znanych przyczyn niepowodzenia, które pomagają kategoryzować i wyjaśnić główną przyczynę. Te wartości mają na celu zastosowanie filtrowania wyjątków i innej logiki, w której inspekcja tekstu komunikatu wyjątku nie byłaby idealna. Niektóre kluczowe przyczyny niepowodzenia to:

    • ServiceTimeout: wskazuje, że usługa Service Bus nie odpowiedziała na żądanie operacji w oczekiwanym czasie. Przyczyną może być przejściowy problem z siecią lub problem z usługą. Usługa Service Bus może lub nie została pomyślnie ukończona. stan nie jest znany. W kontekście następnej dostępnej sesji ten wyjątek wskazuje, że w jednostce nie było żadnych odblokowanych sesji. Te błędy to błędy przejściowe, które są automatycznie ponawiane.

    • QuotaExceeded: zazwyczaj wskazuje, że istnieje zbyt wiele aktywnych operacji odbierania dla pojedynczej jednostki. Aby uniknąć tego błędu, zmniejsz liczbę potencjalnych równoczesnych odbiorów. Odbieranie wsadowe umożliwia podjęcie próby odebrania wielu komunikatów na żądanie odbierania. Aby uzyskać więcej informacji, zobacz Limity przydziału usługi Service Bus.

    • MessageSizeExceeded: wskazuje, że rozmiar komunikatu przekroczył maksymalny rozmiar komunikatu. Rozmiar komunikatu zawiera treść komunikatu i wszystkie skojarzone metadane. Najlepszym podejściem do rozwiązania tego błędu jest zmniejszenie liczby komunikatów wysyłanych w partii lub rozmiar treści zawartej w komunikacie. Ponieważ limity rozmiaru podlegają zmianie, zobacz Limity przydziału usługi Service Bus dla konkretnych elementów.

    • MessageLockLost: wskazuje, że blokada komunikatu zostanie utracona. Osoby wywołujące powinny próbować odbierać i przetwarzać komunikat ponownie. Ten wyjątek dotyczy tylko jednostek, które nie korzystają z sesji. Ten błąd występuje, jeśli przetwarzanie trwa dłużej niż czas trwania blokady, a blokada komunikatu nie jest odnawiana. Ten błąd może również wystąpić, gdy łącze jest odłączone z powodu przejściowego problemu z siecią lub gdy łącze jest bezczynne przez 10 minut.

      Usługa Service Bus używa protokołu AMQP, który jest stanowy. Ze względu na charakter protokołu, jeśli link łączący klienta i usługę jest odłączony po odebraniu komunikatu, ale zanim komunikat zostanie rozstrzygnięty, komunikat nie będzie mógł zostać rozstrzygnięty po ponownym połączeniu linku. Łącza mogą być odłączone z powodu krótkotrwałego przejściowego błędu sieci, awarii sieci lub z powodu wymuszonego 10-minutowego limitu czasu bezczynności usługi. Ponowne połączenie linku odbywa się automatycznie w ramach dowolnej operacji wymagającej linku, czyli rozliczania lub odbierania komunikatów. Ze względu na to zachowanie może wystąpić błąd ServiceBusException lub Reason MessageLockLost SessionLockLost nawet wtedy, gdy czas wygaśnięcia blokady nie minął jeszcze.

    • SessionLockLost: wskazuje, że blokada sesji wygasła. Osoby wywołujące powinny podjąć próbę ponownego zaakceptowania sesji. Ten wyjątek dotyczy tylko jednostek z obsługą sesji. Ten błąd występuje, jeśli przetwarzanie trwa dłużej niż czas trwania blokady, a blokada sesji nie jest odnawiana. Ten błąd może również wystąpić, gdy łącze jest odłączone z powodu przejściowego problemu z siecią lub gdy łącze jest bezczynne przez 10 minut. Usługa Service Bus używa protokołu AMQP, który jest stanowy. Ze względu na charakter protokołu, jeśli link łączący klienta i usługę jest odłączony po odebraniu komunikatu, ale zanim komunikat zostanie rozstrzygnięty, komunikat nie będzie mógł zostać rozstrzygnięty po ponownym połączeniu linku. Łącza mogą być odłączone z powodu krótkotrwałego przejściowego błędu sieci, awarii sieci lub z powodu wymuszonego 10-minutowego limitu czasu bezczynności usługi. Ponowne połączenie linku odbywa się automatycznie w ramach dowolnej operacji wymagającej linku, czyli rozliczania lub odbierania komunikatów. Ze względu na to zachowanie może wystąpić błąd ServiceBusException lub Reason MessageLockLost SessionLockLost nawet wtedy, gdy czas wygaśnięcia blokady nie minął jeszcze.

    • MessageNotFound: Ten błąd występuje podczas próby odebrania komunikatu odroczonego według numeru sekwencji dla komunikatu, który nie istnieje w jednostce lub jest obecnie zablokowany.

    • SessionCannotBeLocked: wskazuje, że żądana sesja nie może być zablokowana, ponieważ blokada jest już przechowywana w innym miejscu. Po wygaśnięciu blokady można zaakceptować sesję.

    • GeneralError: wskazuje, że usługa Service Bus napotkała błąd podczas przetwarzania żądania. Ten błąd jest często spowodowany uaktualnieniami i ponownymi uruchomieniami usługi. Te błędy to błędy przejściowe, które są automatycznie ponawiane.

    • ServiceCommunicationProblem: wskazuje, że wystąpił błąd podczas komunikacji z usługą. Problem może wynikać z przejściowego problemu z siecią lub problemu z usługą. Te błędy to błędy przejściowe, które zostaną automatycznie ponawiane.

    • ServiceBusy: wskazuje, że żądanie zostało ograniczone przez usługę. Szczegóły opisujące, co może spowodować ograniczenie żądania i jak uniknąć ograniczania przepustowości, można znaleźć tutaj. Żądania ograniczone są ponawiane, ale biblioteka klienta automatycznie stosuje 10-sekundowe wycofywanie przed podjęciem próby użycia kolejnych żądań przy użyciu tego samego ServiceBusClient (lub wszelkich podtypów utworzonych na podstawie tego klienta). Może to powodować problemy, jeśli czas trwania blokady jednostki jest krótszy niż 10 sekund, ponieważ blokady komunikatów lub sesji mogą zostać utracone w przypadku niezatłoczonych komunikatów lub zablokowanych sesji. Ponieważ żądania ograniczone są zwykle ponawiane pomyślnie, wygenerowane wyjątki będą rejestrowane jako ostrzeżenia, a nie błędy — określone zdarzenie źródła zdarzeń na poziomie ostrzeżenia to 43 (runOperation napotkał wyjątek i występuje ponowna próba).

    • MessagingEntityAlreadyExists: wskazuje, że jednostka o tej samej nazwie istnieje w tej samej przestrzeni nazw.

    • MessagingEntityDisabled: Jednostka obsługi komunikatów jest wyłączona. Ponownie włącz jednostkę przy użyciu portalu.

    • MessagingEntityNotFound: usługa Service Bus nie może odnaleźć zasobu usługi Service Bus.

Obsługa elementu ServiceBusException — przykład

Oto przykład obsługi metody ServiceBusException i filtrowania według elementu Reason.

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

Inne typowe wyjątki

  • ArgumentException: Klient zgłasza ten wyjątek pochodzący z ArgumentException parametru podanego podczas interakcji z klientem jest nieprawidłowy. Informacje o określonym parametrze i charakterze problemu można znaleźć w pliku Message.
  • InvalidOperationException: występuje podczas próby wykonania operacji, która nie jest prawidłowa dla bieżącej konfiguracji. Ten wyjątek zwykle występuje, gdy klient nie został skonfigurowany do obsługi operacji. Często można temu zapobiec, dostosowując opcje przekazywane do klienta.
  • NotSupportedException: występuje, gdy żądana operacja jest prawidłowa dla klienta, ale nie jest obsługiwana przez jego bieżący stan. Informacje o scenariuszu można znaleźć w pliku Message.
  • AggregateException: występuje, gdy operacja może napotkać wiele wyjątków i pojawia się je jako pojedynczy błąd. Ten wyjątek występuje najczęściej podczas uruchamiania lub zatrzymywania procesora usługi Service Bus lub procesora sesji usługi Service Bus.

Przyczyna: QuotaExceeded

ServiceBusException z ustawioną QuotaExceeded przyczyną wskazuje, że przekroczono limit przydziału określonej jednostki.

Uwaga

Aby zapoznać się z limitami przydziału usługi Service Bus, zobacz Limity przydziału.

Kolejki i tematy

W przypadku kolejek i tematów często jest to rozmiar kolejki. Właściwość komunikatu o błędzie zawiera dalsze szczegóły, jak w poniższym przykładzie:

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

Komunikat informuje, że temat przekroczył limit rozmiaru, w tym przypadku 1 GB (domyślny limit rozmiaru).

Przestrzenie nazw

W przypadku przestrzeni nazw wyjątek QuotaExceeded może wskazywać, że aplikacja przekroczyła maksymalną liczbę połączeń z przestrzenią nazw. Na przykład:

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

Typowe przyczyny

Istnieją dwie typowe przyczyny tego błędu: kolejka utraconych komunikatów i niefunkcjonujące odbiorniki komunikatów.

  • Kolejka utraconych komunikatów Czytnik kończy się niepowodzeniem, a komunikaty są zwracane do kolejki/tematu po wygaśnięciu blokady. Może się zdarzyć, jeśli czytelnik napotka wyjątek uniemożliwiający ukończenie komunikatu. Po odczytaniu komunikatu 10 razy domyślnie przechodzi do kolejki utraconych komunikatów. To zachowanie jest kontrolowane przez właściwość MaxDeliveryCount i ma wartość domyślną 10. W miarę stosu komunikatów w kolejce utraconych wiadomości zajmują miejsce.

    Aby rozwiązać ten problem, przeczytaj i ukończ komunikaty z kolejki utraconych komunikatów, tak jak w przypadku każdej innej kolejki.

  • Odbiornik został zatrzymany. Odbiorca przestał odbierać komunikaty z kolejki lub subskrypcji. Sposobem zidentyfikowania problemu jest przyjrzenie się aktywnej liczbie komunikatów. Jeśli liczba aktywnych komunikatów jest wysoka lub rośnie, komunikaty nie są odczytywane tak szybko, jak są zapisywane.

Przyczyna: MessageLockLost

Przyczyna

ServiceBusException z ustawioną MessageLockLost przyczyną wskazuje, że komunikat jest odbierany przy użyciu trybu odbierania PeekLock i blokada przechowywana przez klienta wygasa po stronie usługi.

Blokada komunikatu może wygasnąć z różnych powodów:

  • Czasomierz blokady wygasł przed jego odnowieniem przez aplikację kliencą.
  • Aplikacja kliencka uzyskała blokadę, zapisała ją w magazynie trwałym, a następnie została ponownie uruchomiona. Po ponownym uruchomieniu aplikacja kliencka spojrzała na komunikaty inflight i próbowała ukończyć komunikaty.

Ten wyjątek może również zostać wyświetlony w następujących scenariuszach:

  • Aktualizacja usługi
  • Aktualizacja systemu operacyjnego
  • Zmiana właściwości jednostki (kolejka, temat, subskrypcja) podczas przechowywania blokady.

Rozwiązanie

Gdy aplikacja kliencka odbiera komunikat MessageLockLostException, nie może już przetworzyć komunikatu. Aplikacja kliencka może opcjonalnie rozważyć rejestrowanie wyjątku do analizy, ale klient musi usunąć komunikat.

Ponieważ blokada komunikatu wygasła, nastąpi powrót do kolejki (lub subskrypcji) i może zostać przetworzona przez następną aplikację kliencką, która wywołuje odbieranie.

Jeśli parametr MaxDeliveryCount został przekroczony, komunikat może zostać przeniesiony do kolejki DeadLetterQueue.

Przyczyna: SessionLockLost

Przyczyna

Wyjątek ServiceBusException z ustawioną MessageLockLost przyczyną jest zgłaszany po zaakceptowaniu sesji, a blokada przechowywana przez klienta wygasa po stronie usługi.

Blokada sesji może wygasnąć z różnych powodów:

  • Czasomierz blokady wygasł przed jego odnowieniem przez aplikację kliencą.
  • Aplikacja kliencka uzyskała blokadę, zapisała ją w magazynie trwałym, a następnie została ponownie uruchomiona. Po ponownym uruchomieniu aplikacja kliencka spojrzała na sesje inflight i próbowała przetworzyć komunikaty w tych sesjach.

Ten wyjątek może również zostać wyświetlony w następujących scenariuszach:

  • Aktualizacja usługi
  • Aktualizacja systemu operacyjnego
  • Zmiana właściwości jednostki (kolejka, temat, subskrypcja) podczas przechowywania blokady.

Rozwiązanie

Gdy aplikacja kliencka odbiera wyjątek SessionLockLostException, nie może już przetwarzać komunikatów w sesji. Aplikacja kliencka może rozważyć rejestrowanie wyjątku do analizy, ale klient musi usunąć komunikat.

Ponieważ blokada sesji wygasła, nastąpi powrót do kolejki (lub subskrypcji) i może zostać zablokowana przez następną aplikację kliencką, która akceptuje sesję. Ponieważ blokada sesji jest przechowywana przez jedną aplikację kliencką w danym momencie, gwarantowane jest przetwarzanie w kolejności.

TimeoutException

Wyjątek TimeoutException zazwyczaj wskazuje na to, że operacja zainicjowana przez użytkownika zajmuje więcej czasu niż wynosi limit czasu dla operacji.

Należy sprawdzić wartość właściwości ServicePointManager.DefaultConnectionLimit , ponieważ przekroczenie tego limitu może również spowodować wyjątek TimeoutException.

Oczekuje się, że przekroczenia limitów czasu będą mieć miejsce podczas operacji konserwacji lub między nimi, takich jak aktualizacje usługi Service Bus (lub) aktualizacje systemu operacyjnego dotyczące zasobów, na których jest uruchamiana usługa. Podczas aktualizacji systemu operacyjnego jednostki są przenoszone, a węzły aktualizowane lub ponownie uruchamiane, co może powodować przekraczanie limitów czasu. Aby uzyskać szczegółowe informacje o umowie dotyczącej poziomu usługi (SLA) dla usługi Azure Service Bus, zobacz Umowa SLA dla usługi Service Bus.

SocketException

Przyczyna

Wyjątek SocketException jest zgłaszany w następujących przypadkach:

  • Gdy próba połączenia zakończy się niepowodzeniem, ponieważ host nie odpowiedział prawidłowo po upływie określonego czasu (kod błędu TCP 10060).
  • Nawiązane połączenie nie powiodło się, ponieważ nie można odpowiedzieć na połączony host.
  • Wystąpił błąd podczas przetwarzania komunikatu lub przekroczenie limitu czasu przez hosta zdalnego.
  • Problem z podstawowym zasobem sieci.

Rozwiązanie

Błędy SocketException wskazują, że maszyna wirtualna hostująca aplikacje nie może przekonwertować nazwy <mynamespace>.servicebus.windows.net na odpowiedni adres IP.

Sprawdź, czy następujące polecenie zakończy się pomyślnie mapowaniem na adres IP.

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

Które powinny dostarczyć dane wyjściowe, takie jak:

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

Jeśli powyższa nazwa nie jest rozpoznawana jako adres IP i alias przestrzeni nazw, zapoznaj się z administratorem sieci, aby dokładniej zbadać problem. Rozpoznawanie nazw odbywa się za pośrednictwem serwera DNS zazwyczaj zasobu w sieci klienta. Jeśli rozpoznawanie nazw DNS jest wykonywane przez usługę Azure DNS, skontaktuj się z pomoc techniczna platformy Azure.

Jeśli rozpoznawanie nazw działa zgodnie z oczekiwaniami, sprawdź, czy połączenia z usługą Azure Service Bus są dozwolone tutaj.

Brak autoryzacji dostępu

Brak autoryzacjiaccessException wskazuje, że podane poświadczenia nie zezwalają na wykonanie żądanej akcji. Właściwość Message zawiera szczegółowe informacje o błędzie.

Zalecamy wykonanie tych kroków weryfikacji w zależności od typu autoryzacji podanego podczas konstruowania obiektu ServiceBusClient.

Wyjątki replikacji geograficznej

ServerBusyException

Przyczyny

  • Podczas replikacji asynchronicznej (opóźnienie replikacji większe niż zero) klient próbuje wykonać operację na jednostce usługi Service Bus (kolejce, temacie) lub wykonuje operację zarządzania, ale nie można ukończyć operacji, ponieważ opóźnienie replikacji między regionami podstawowymi i pomocniczymi przekroczyło maksymalne dozwolone opóźnienie replikacji w sekundach.
    • Przykład: operacja jest ograniczana, ponieważ wraz z nim nowe opóźnienie replikacji osiągnie 38 323 sekundy, co jest większe niż maksymalne opóźnienie replikacji ustawione (300 sekund). Bieżące opóźnienie replikacji dla najnowszej replikowanej operacji wynosi 0 sekund.
  • Kolejka replikacji dla jednostki przekracza maksymalny rozmiar w bajtach. Maksymalny rozmiar w bajtach dla kolejki replikacji to wewnętrzny limit ustawiony przez usługę Service Bus.
    • Przykład: rozmiar kolejki replikacji 73128000 przekroczył próg 67108864.
  • W przypadku replikacji synchronicznej limit czasu żądania trwa oczekiwanie na replikowanie innego żądania.
    • Przykład: duża liczba żądań z aplikacji klienckiej dla skarri-storage-exp1(westus3)/q1:MessagingJournal. Trwa replikacja do innych regionów.

Rozwiązanie

  • Klient powinien wycofać się, aby dać usłudze czas na przetworzenie danego obciążenia, a następnie klient powinien ponowić próbę.

Timeout

Przyczyna

  • Wyjątek przekroczenia limitu czasu w usłudze Geo DR oznacza, że operacja nie została ukończona w ramach limitu czasu dostarczonego przez klienta.
    • W przypadku replikacji synchronicznej zapis i replikacja regionu podstawowego operacji do regionów pomocniczych znajdują się w zakresie limitu czasu operacji.
    • W przypadku replikacji asynchronicznej zapis regionu podstawowego operacji mieści się w zakresie limitu czasu operacji, ale replikacja operacji do regionów pomocniczych nie mieści się w zakresie limitu czasu operacji.
    • Przykład: operacja nie została ukończona w ramach przydzielonego czasu 00:01:00 dla komunikatu o obiekcie. (ServiceTimeout).

Rozwiązanie

  • Klient powinien ponowić próbę wykonania operacji.
  • Niektóre kroki operacji przekroczenia limitu czasu mogły zostać ukończone. Możliwe, że operacja przekroczenia limitu czasu mogła zostać zapisana w regionie podstawowym i w niektórych regionach pomocniczych. Jeśli operacja została zapisana w regionie podstawowym, zostanie ona ostatecznie zreplikowana do wszystkich regionów pomocniczych niezależnie od limitu czasu klienta.

BadRequest

Przyczyna

  • Podczas planowanego przejścia w tryb failover region podstawowy jest tymczasowo ustawiany jako tylko do odczytu, aby umożliwić nadrobienie zaległości w regionie pomocniczym. Jeśli klient próbuje wykonać operację zapisu w regionie podstawowym, gdy jest w tym tymczasowym stanie tylko do odczytu, klient otrzymuje wyjątek BadRequest.
    • Przykład: Trwa przełączanie roli replikacji, replika podstawowa:<nazwa-jednostki> to ReadOnly.

Rozwiązanie

  • Klient musi poczekać na ukończenie planowanego przejścia w tryb failover, zanim operacje zapisu zakończą się pomyślnie.
  • W przypadku, gdy planowane przejście w tryb failover trwa zbyt długo, można zamiast tego wyzwolić wymuszone przejście w tryb failover.

Następne kroki

Aby uzyskać pełną dokumentację interfejsu API platformy .NET usługi Service Bus, zobacz dokumentację interfejsu API platformy .NET platformy Azure. Aby uzyskać porady dotyczące rozwiązywania problemów, zobacz Przewodnik rozwiązywania problemów.