Condividi tramite

Trasferimento

In questo argomento viene descritto il trasferimento nel modello di traccia delle attività di Windows Communication Foundation (WCF).

Definizione di trasferimento

I trasferimenti tra attività rappresentano relazioni causali tra eventi nelle attività correlate all'interno degli endpoint. Due attività sono correlate ai trasferimenti quando il flusso di controllo passa tra di esse, ad esempio, una chiamata al metodo che attraversa i confini dell'attività. In WCF, quando i byte sono in ingresso nel servizio, l'attività Listen At viene trasferita all'attività Receive Bytes in cui viene creato l'oggetto messaggio. Per un elenco degli scenari di tracciamento end-to-end e delle rispettive attività e progettazione di tracciamento, vedere Scenari di tracciamento end-To-End.

Per generare tracce di trasferimento, usare l'impostazione ActivityTracing sull'origine di traccia, come illustrato dal codice di configurazione seguente.

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

Uso del trasferimento per correlare le attività all'interno degli endpoint

Le attività e i trasferimenti consentono all'utente di individuare in modo probabilistico la causa radice di un errore. Ad esempio, se trasferiamo avanti e indietro tra le attività M e N rispettivamente nei componenti M e N, e si verifica un arresto anomalo in N subito dopo il ritorno a M, possiamo concludere che è probabile che ciò sia dovuto al passaggio dei dati da N a M.

Una traccia di trasferimento viene generata dall'attività M all'attività N quando è presente un flusso di controllo tra M e N. Ad esempio, N esegue alcune operazioni per M a causa di una chiamata di metodo che supera i limiti delle attività. N può esistere già o è stato creato. N viene generato da M quando N è una nuova attività che esegue alcune operazioni per M.

Un trasferimento da M a N potrebbe non essere seguito da un trasferimento da N a M. Questo perché M può generare qualche lavoro in N e non tenere traccia quando N completa il lavoro. Infatti, M può terminare prima che N completi l'attività. Ciò si verifica nell'attività "Open ServiceHost" (M) che genera attività listener (N) e quindi termina. Un trasferimento da N a M significa che N ha completato il lavoro correlato a M.

N può continuare a eseguire altre elaborazioni non correlate a M, ad esempio un'attività di autenticazione esistente (N) che continua a ricevere richieste di accesso (M) da attività di accesso diverse.

Una relazione di annidamento non esiste necessariamente tra le attività M e N. Ciò può verificarsi a causa di due motivi. Primo, quando l'attività M non monitora l'elaborazione effettiva eseguita in N anche se M ha avviato N. Secondo, quando N esiste già.

Esempio di trasferimenti

Di seguito sono elencati due esempi di trasferimento.

  • Quando si crea un host del servizio, il costruttore assume il controllo dal codice chiamante o il codice chiamante lo trasferisce al costruttore. Al termine dell'esecuzione del costruttore, il controllo viene restituito al codice chiamante, oppure il costruttore ritorna al codice che l'ha invocato. Questo è il caso di una relazione annidata.

  • Quando un listener avvia l'elaborazione dei dati di trasporto, crea un nuovo thread e passa all'attività "Receive Bytes" il contesto appropriato per l'elaborazione, passando i dati e il controllo. Al termine dell'elaborazione della richiesta, l'attività Receive Bytes non restituisce nulla al listener. In questo caso, abbiamo un trasferimento in entrata ma nessun trasferimento in uscita dalla nuova attività thread. Le due attività sono correlate ma non annidate.

Sequenza di trasferimento delle attività

Una sequenza di trasferimento di attività ben formata include i passaggi seguenti.

  1. Iniziare una nuova attività, costituita dalla selezione di un nuovo gAId.

  2. Generare un tracciato di trasferimento verso quel nuovo gAId dall'ID attività corrente

  3. Impostare il nuovo ID in TLS

  4. Generare una traccia iniziale per indicare l'inizio della nuova attività.

  5. Tornare all'attività originale è costituita dai seguenti elementi:

  6. Generare una traccia di trasferimento al gAId originale

  7. Generare una traccia Stop per indicare la fine della nuova attività

  8. Impostare TLS sul vecchio gAId.

Nell'esempio di codice seguente viene illustrato come eseguire questa operazione. In questo esempio si presuppone che venga effettuata una chiamata di blocco durante il trasferimento alla nuova attività e includa tracce di sospensione/ripresa.

// 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);

Vedere anche

  • Last updated on