błędy Server-Side

Odbiornik i gracz współpracują ze sobą, aby poradzić sobie z zatrutymi wiadomościami. Jeśli odtwarzana transakcja zakończy się niepowodzeniem, kolejkowanie komunikatów przenosi komunikat wejściowy z powrotem do kolejki wejściowej. Gracz przerywa transakcję, jeśli otrzyma błąd HRESULT ze składnika serwera lub jeśli przechwyci wyjątek. Jeśli problem będzie się powtarzać, odbiornik może w sposób ciągły występować w następującym wzorcu:

• Dequeues komunikatu
• Tworzy wystąpienie obiektu
• Cierpi na wycofanie
• Umieszcza komunikat z powrotem w górnej części kolejki

Usługa składników w kolejce obsługuje ten błąd przy użyciu serii kolejek ponawiania prób specyficznych dla aplikacji. Utworzony po zainstalowaniu składnika istnieje siedem kolejek dla każdej aplikacji w następujący sposób:

1. Normalna kolejka wejściowa. Nazwa tej kolejki to nazwa aplikacji COM+ . Jest to kolejka publiczna kolejki kolejki komunikatów.

2. Pierwsza kolejka ponawiania prób. Komunikaty są przenoszone w tym miejscu, jeśli transakcja wielokrotnie kończy się niepowodzeniem podczas przetwarzania komunikatów z normalnej kolejki wejściowej. Komunikaty w tej kolejce są przetwarzane po jednej minucie. Komunikat można ponowić trzy razy w tej kolejce przed przeniesieniem do tyłu drugiej kolejki ponawiania prób. Ta kolejka ma nazwę ApplicationName_0. Ta kolejka jest prywatną kolejką kolejkowania komunikatów.

3. Druga kolejka ponawiania prób. Komunikaty są przenoszone w tym miejscu, jeśli transakcja wielokrotnie kończy się niepowodzeniem podczas przetwarzania komunikatów z pierwszej kolejki ponawiania prób. Komunikaty w tej kolejce są przetwarzane po dwóch minutach. Komunikat można ponowić trzy razy w tej kolejce przed przeniesieniem do tyłu trzeciej kolejki ponawiania prób. Ta kolejka ma nazwę ApplicationName_1. Ta kolejka jest prywatną kolejką kolejkowania komunikatów.

4. Trzecia kolejka ponawiania prób. Komunikaty są przenoszone w tym miejscu, jeśli transakcja wielokrotnie kończy się niepowodzeniem podczas przetwarzania komunikatów z drugiej kolejki ponawiania prób. Komunikaty w tej kolejce są przetwarzane po czterech minutach. Komunikat można ponowić trzy razy w tej kolejce przed przeniesieniem z powrotem czwartej kolejki ponawiania prób. Ta kolejka ma nazwę ApplicationName_2. Ta kolejka jest prywatną kolejką kolejkowania komunikatów.

5. Czwarta kolejka ponawiania prób. Komunikaty są przenoszone w tym miejscu, jeśli transakcja wielokrotnie kończy się niepowodzeniem podczas przetwarzania komunikatów z trzeciej kolejki ponawiania prób. Komunikaty w tej kolejce są przetwarzane po ośmiu minutach. Komunikat można ponowić trzy razy w tej kolejce przed przeniesieniem do piątej kolejki ponawiania prób. Ta kolejka ma nazwę ApplicationName_3. Ta kolejka jest prywatną kolejką kolejkowania komunikatów.

6. Piąta kolejka ponawiania prób. Komunikaty są przenoszone w tym miejscu, jeśli transakcja wielokrotnie kończy się niepowodzeniem podczas przetwarzania komunikatów z czwartej kolejki ponawiania prób. Komunikaty w tej kolejce są przetwarzane po szesnastu minutach. Komunikat można ponowić trzy razy w tej kolejce, zanim zostanie przeniesiony do końcowej kolejki odpoczynku. Ta kolejka ma nazwę ApplicationName_4. Jest to prywatna kolejka kolejkowania komunikatów.

7. Końcowa kolejka restingu specyficzna dla aplikacji. Komunikaty są przenoszone w tym miejscu, jeśli transakcja wielokrotnie przerywa się podczas próby w piątej kolejce ponawiania prób. Ta kolejka ma nazwę ApplicationName_DeadQueue. Jest to prywatna kolejka kolejkowania komunikatów. Końcowa kolejka spoczynku nie jest serwisowana przez odbiornik kolejki. Komunikaty pozostają tutaj, dopóki nie zostaną ręcznie przeniesione (być może przez narzędzie mover komunikatów o składnikach w kolejce) lub są czyszczone przez Eksploratora kolejkowania komunikatów.

Komunikaty, które nie można odtworzyć, ponieważ jest jasne, że każda próba ponawiania próby zakończy się niepowodzeniem, może zostać przeniesiona bezpośrednio do końcowej kolejki odpoczynku specyficznej dla aplikacji bez przechodzenia przez wszystkie poziomy ponawiania prób.

Gracz wystawia wydarzenie COM+ w celu powiadomienia zainteresowanych stron, że wiadomości nie mogą być odtwarzane. Zdarzenia COM+ są wystawiane w następujących sytuacjach:

• Po przerwaniu transakcji
• Po przeniesieniu komunikatu z jednej kolejki do innej
• Gdy komunikat zostanie zdeponowany do ostatniej kolejki spoczynku

Komunikaty można modyfikować przed przejściem z jednej kolejki do innej. Mechanizm zabezpieczeń składników COM+ w kolejce umożliwia przeniesienie komunikatu do kolejek ponawiania prób, a następnie ponownego przesłania do początkowej kolejki wejściowej aplikacji. Aby uzyskać więcej informacji na temat zabezpieczeń składników w kolejce, zobacz Queued Components Security.

Kolejki ponawiania są tworzone wraz z główną kolejką aplikacji, gdy aplikacja jest oznaczona jako w kolejce przez narzędzie administracyjne usług składników lub za pomocą funkcji ZESTAWU SDK administracyjnego COM+. Usługa składników w kolejce umożliwia elastyczność mechanizmu ponawiania prób, umożliwiając usuwanie kolejek ponawiania prób. Jeśli na przykład wszystkie kolejki ponawiania prób zostaną usunięte, komunikat, który trwale przerywa zostanie przeniesiony bezpośrednio z kolejki aplikacji do końcowej kolejki aplikacji. Usuwając co najmniej jedną kolejkę ponawiania prób, można zmniejszyć liczbę i długość ponownych prób. Jeśli kolejki zostaną usunięte z sekwencji ponawiania prób, czas pozostałych kolejek odpowiada pozycji w sekwencji ponownych kolejek. Jeśli na przykład usuniesz kolejkę ponawiania ApplicationName_1, ApplicationName_2 i ApplicationName_3, komunikaty w ApplicationName_4 będą przetwarzane tak, jakby kolejka była drugą kolejką ponawiania.

Mechanizm ponawiania prób został zaprojektowany w celu ukończenia komunikatu, jeśli w ogóle jest to możliwe. W niektórych przypadkach komunikat może nie być możliwy do pomyślnego działania. Na przykład klient może próbować wypłacić pieniądze z konta, które ma niewystarczające fundusze. W takich okolicznościach można obsłużyć błąd na wiele sposobów, w tym następujące:

• Generowanie diagnostyki i wystawianie ostrzeżenia
• Tworzenie transakcji wyrównywczej
• Ignoruj problem i odrzucaj komunikat

Podobnie jak trwałe błędy po stronie klienta, usługa składników w kolejce umożliwia skojarzenie klasy wyjątków ze składnikiem. Klasa wyjątku jest skojarzona ze składnikiem przy użyciu karty Zaawansowane na stronie właściwości składnika narzędzia administracyjnego usług składników lub za pomocą funkcji administracyjnych COM+. Klasa wyjątków umożliwia deweloperowi kontrolę po ponowieniu próby i przed przeniesieniem tego komunikatu do końcowej kolejki odpoczynku specyficznej dla aplikacji. Aby uzyskać więcej informacji na temat klasy wyjątków, zobacz Trwałe błędy Client-Side.

Poniżej przedstawiono sekwencję zdarzeń obsługi wyjątków po stronie serwera:

1. Komunikat jest przenoszony przez dostępne kolejki ponawiania prób specyficznych dla aplikacji.
2. Ostatnia ponowna próba w ostatniej kolejce ponawiania nie powiedzie się.
3. Czas wykonywania usługi składników w kolejce pobiera składnik docelowy z komunikatu i sprawdza klasę wyjątków.
4. Wystąpienie klasy wyjątku jest tworzone w czasie wykonywania.
5. Zapytania w czasie wykonywania IPlaybackControl w klasie wyjątków.
6. Wywołania w czasie wykonywania IPlaybackControl::FinalServerRetry w klasie wyjątku.
7. Czas wykonywania odtwarza wszystkie wywołania właściwości i metody z komunikatu do klasy wyjątku.
8. Jeśli kroki od 4 do 6 nie powiedzie się, czas wykonywania przenosi komunikat do kolejki końcowej specyficznej dla aplikacji.

Jeśli musisz interweniować w procesie opisanym powyżej lub musisz przenieść komunikat trucizny z końcowej kolejki odpoczynku, użyj narzędzia mover komunikatów. Aby uzyskać więcej informacji na temat narzędzia mover komunikatów, zobacz Obsługa błędów.

Tematy pokrewne

błędy Client-Side

trwałe błędy Client-Side