HandleError vs. ProvideFault niespójności w usłudze przepływu pracy, jak sobie z nią poradzić?

Question

W naszej usłudze przepływu pracy WF4 staramy się być maksymalnie odporni. Jedną z rzeczy, które robimy, jest rejestrowanie błędów wewnątrz HandleError i ProvideFault (IErrorhandler). Państwa dokumentacja wyraźnie, że HandleError byłby właściwym miejscem, aby wykonać logowania, ale widzę jakieś dziwne rzeczy dzieją się:

1. widzę pewne błędy, które tylko powodują ProvideFault, ale nigdy HandleError jednym przykładzie wynosił:

   System.NullReferenceException: Odniesienie do obiektu nie jest ustawione na wystąpienie obiektu. na System.ServiceModel.Activities.Dispatcher.DurableInstanceManager.GetInstanceAsyncResult.GetInstance() na System.ServiceModel.Activities.Dispatcher.DurableInstanceManager.GetInstanceAsyncResult..ctor

2. Istnieją również pewne błędy, które tylko powodują HandleError , ale nigdy ProvideFault, jeden przykład:

   System.ServiceModel.CommunicationException: Wystąpił błąd odczytu z rury: Rura została zakończona. (109, 0x6d). w System.ServiceModel.Channels.PipeConnection.Read (bajty [] bufor Int32 offset, wielkość Int32, przekroczenie czasu TimeSpan) w System.ServiceModel.Channels.SessionConnectionReader.Receive (TimeSpan czasu oczekiwania)

3. Wreszcie istnieją błędy, które wyzwalają zarówno, najpierw ProvideFault a następnie HandleError (na wątek tła)

4. Jeśli to możliwe, chcę zalogować się odpowiedni komunikat przychodzący, too. Czynię to z OperationContext.Current.RequestContext.RequestMessage.ToString() To zazwyczaj działa tylko w ProvideFault w HandleError nie mają RequestContext więcej

Więc mój wniosek był, aby rejestrować wszystkie błędy, muszę zalogować się w obu metodach. Ale to prowadzi do wielu zduplikowanych wpisów w dzienniku, z powodu 3. ..

Moje bieżące obejście polegało na "zapamiętywaniu" ostatniego zalogowanego wyjątku od ProvideFault i ignorowaniu go, jeśli ten sam wyjątek wchodzi do HandleError. Wygląda na to, że nie jest dla mnie zbyt czysty.

Czy ktokolwiek jest lepszym, niezawodnym sposobem rejestrowania wszystkie błędy, które mogą się zdarzyć w ramach usługi WF?

Proszę nie wskazywać na Logging exceptions in WCF with IErrorHandler inside HandleError or ProvideFault?, ponieważ nie zapewnia to żadnej pomocy.

Answer 1

Widziałem scenariusz 2 zdarzyć w innym kontekście (adapter BizTalk) i wydaje się, że HandleError nazywa bo jest wyjątek, który występuje w adapterze, ale ProvideFault jest nie nazywa, bo nie ma wiadomość do rzeczywistości return - błąd wystąpił w taki sposób, że uniemożliwiał adapterowi generowanie/odczytywanie/tłumaczenie komunikatu i przekazywanie go do potoku. Wydaje się to uniemożliwiać wygenerowanie nawet komunikatu o błędzie o błędzie.Nieprawidłowe odczytanie z potoku wydaje się to stanowić - twoja usługa nie wie, czy się nie powiodło, ponieważ nigdy się nie połączyła lub jeśli się nie udało, ponieważ zdalny serwer zawiódł. Rzeczy takie jak TransactionAbortedException mogą również powodować to, lub (w moim szczególnym przypadku), może spowodować to SqlException.

To powinno dać pewną wskazówkę w przypadku nr 1, którego nie widziałem ani nie rozmnażałem: wynika to z niewłaściwego obchodzenia się z wyjątkami w łańcuchu wiadomości. W tym przypadku wygenerowano komunikat o błędzie, ale coś znajdującego się wyżej w łańcuchu nie poradziło sobie z wyjątkiem w taki sposób, że można było wywołać HandleError. A NullReferenceException ma sens - jeśli nie wykonasz poprawnie kontroli zerowych, trudno powiedzieć, co jeszcze może się wydarzyć w takim przypadku.

Jeśli chodzi o rozwiązywanie tego problemu, prawdopodobnie spróbuję zalogować się w obu miejscach, z dodatkowymi informacjami wyjaśniającymi, skąd pochodzi dziennik. To byłoby bezpieczne, nawet jeśli robi to zduplikowane logowanie. Z drugiej strony, jeśli masz listę wyjątków, które generują jeden lub oba te scenariusze, możesz wdrożyć logikę, aby sprawdzić, jaki rodzaj wyjątku jest (lub gdzie wystąpił) - być może robiąc mniej rejestrowania, jeśli jest to wyjątek prawdopodobnie będzie obsługiwana inną metodą.