Udostępnij przez

Przenoszenie

W tym temacie opisano transfer w modelu śledzenia działań programu Windows Communication Foundation (WCF).

Definicja transferu

Transfery między działaniami reprezentują relacje przyczynowe między zdarzeniami w powiązanych działaniach w punktach końcowych. Dwie aktywności są powiązane z transferami, gdy przepływ sterowania odbywa się między nimi, na przykład gdy wywołanie metody przekracza granice aktywności. W WCF, gdy bajty przychodzą do usługi, działanie Nasłuchiwania jest przenoszone do działania Odbioru Bajtów, gdzie tworzony jest obiekt wiadomości. Aby zapoznać się z listą scenariuszy kompleksowego śledzenia oraz ich odpowiedniego projektu działań i śledzenia, zobacz End-To-End Tracing Scenarios (Scenariusze śledzenia end-To-End).

Aby włączyć logi transferu, użyj ustawienia ActivityTracing w źródle śledzenia, jak pokazano w poniższym kodzie konfiguracji.

<source name="System.ServiceModel" switchValue="Verbose,ActivityTracing">

Używanie transferu do korelowania działań w punktach końcowych

Działania i transfery umożliwiają użytkownikowi probabilistycznie zlokalizowanie głównej przyczyny błędu. Na przykład, jeśli przełączamy się pomiędzy działaniami M i N odpowiednio zlokalizowanymi w komponentach M i N, a awaria wystąpi w N zaraz po powrocie do działania M, możemy dojść do wniosku, że prawdopodobnie jest to spowodowane przekazaniem danych przez N z powrotem do M.

Ślad transferu jest emitowany z działania M do działania N, gdy istnieje przepływ kontroli między M a N. Na przykład N wykonuje pewną pracę dla M z powodu wywołania metody przekraczającego granice działań. N może już istnieć lub został utworzony. N jest wywoływane przez M, gdy N jest nowym działaniem, które wykonuje jakąś pracę dla M.

Transfer z M do N może nie następować z powrotem z N do M. Jest to spowodowane tym, że M może rozpocząć pewną pracę w N i nie śledzi, kiedy N zakończy tę pracę. W rzeczywistości język M może zakończyć działanie, zanim N zakończy swoje zadanie. Dzieje się tak w działaniu "Open ServiceHost" (M), które generuje działania odbiornika (N), a następnie się kończy. Powrót z N do M oznacza, że N zakończył wykonanie pracy związanej z M.

N może nadal wykonywać inne przetwarzanie niepowiązane z M, na przykład istniejące działanie wystawcy uwierzytelniania (N), które utrzymuje odbieranie żądań logowania (M) z różnych działań logowania.

Relacja zagnieżdżania nie musi istnieć między działaniami M i N. Może się to zdarzyć z dwóch powodów. Po pierwsze, gdy działanie M nie monitoruje rzeczywistego przetwarzania wykonywanego w N, chociaż M zainicjował N. Po drugie, gdy N już istnieje.

Przykład transferów

Poniżej wymieniono dwa przykłady transferu.

  • Podczas tworzenia hosta usługi, konstruktor przejmuje kontrolę od kodu wywołującego lub kod wywołujący przekazuje kontrolę do konstruktora. Po zakończeniu wykonywania konstruktora zwraca kontrolkę do kodu wywołującego lub konstruktor przekazuje go z powrotem do kodu wywołującego. Jest to przypadek relacji zagnieżdżonej.

  • Gdy nasłuchujący zacznie przetwarzać dane transportu, tworzy nowy wątek i przekazuje do działania Receive Bytes odpowiedni kontekst do przetwarzania, umożliwiając przekazywanie kontroli i danych. Po zakończeniu przetwarzania żądania w tym wątku działanie Odbierz bajty nie przekazuje niczego z powrotem do odbiornika. W tym przypadku mamy przeniesienie do, ale brak przeniesienia z nowej aktywności wątku. Te dwa działania są powiązane, ale nie są zagnieżdżone.

Sekwencja transferu działań

Dobrze sformułowana sekwencja transferu działań obejmuje następujące kroki.

  1. Rozpocznij nowe działanie, które składa się z wybierania nowego identyfikatora gAId.

  2. Generuj ślad transferu do tego nowego identyfikatora gAId z bieżącego identyfikatora aktywności

  3. Ustawianie nowego identyfikatora w protokole TLS

  4. Emituj ślad rozpoczęcia, aby wskazać początek nowego działania.

  5. Powrót do oryginalnego działania składa się z następujących elementów:

  6. Emituj ślad transferu do oryginalnego identyfikatora gAId

  7. Emituj ślad zatrzymania, aby wskazać koniec nowego działania

  8. Ustaw TLS na stary identyfikator gAId.

W poniższym przykładzie kodu pokazano, jak to zrobić. Zakłada się, że podczas przejścia do nowego działania wykonywane jest wywołanie blokujące. Obejmuje ono również ślady wstrzymania/wznowienia.

// 0. Create a trace source  
TraceSource ts = new TraceSource("myTS");  

// 1. remember existing ("ambient") activity for clean up  
Guid oldGuid = Trace.CorrelationManager.ActivityId;  
// this will be our new activity  
Guid newGuid = Guid.NewGuid();

// 2. call transfer, indicating that we are switching to the new AID  
ts.TraceTransfer(667, "Transferring.", newGuid);  

// 3. Suspend the current activity.  
ts.TraceEvent(TraceEventType.Suspend, 667, "Suspend: Activity " + i-1);  

// 4. set the new AID in TLS  
Trace.CorrelationManager.ActivityId = newGuid;  

// 5. Emit the start trace  
ts.TraceEvent(TraceEventType.Start, 667, "Boundary: Activity " + i);  

// trace something  
ts.TraceEvent(TraceEventType.Information, 667, "Hello from activity " + i);  

// Perform Work  
// some work.  
// Return  
ts.TraceEvent(TraceEventType.Information, 667, "Work complete on activity " + i);

// 6. Emit the transfer returning to the original activity  
ts.TraceTransfer(667, "Transferring Back.", oldGuid);  

// 7. Emit the End trace  
ts.TraceEvent(TraceEventType.Stop, 667, "Boundary: Activity " + i);  

// 8. Change the tls variable to the original AID  
Trace.CorrelationManager.ActivityId = oldGuid;

// 9. Resume the old activity  
ts.TraceEvent(TraceEventType.Resume, 667, "Resume: Activity " + i-1);

Zobacz także

  • Last updated on