Partilhar via

Transferência

Este tópico descreve a transferência no modelo de rastreamento de atividades do Windows Communication Foundation (WCF).

Definição de transferência

As transferências entre atividades representam relações causais entre eventos nas atividades relacionadas nos extremos. Duas atividades estão relacionadas com transferências quando ocorre transferência de controlo entre elas, por exemplo, quando um método atravessa as fronteiras da atividade. No WCF, quando bytes são recebidos no serviço, a atividade Ouvir em é transferida para a atividade Receber bytes onde o objeto de mensagem é criado. Para uma lista de cenários de rastreamento de ponta a ponta, e suas respetivas atividades e design de rastreamento, consulte End-To-End Tracing Scenarios.

Para emitir registos de transferência, utilize a definição ActivityTracing na origem do rastreamento, conforme demonstrado pelo código de configuração a seguir.

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

Usando a transferência para correlacionar atividades dentro de endpoints

Atividades e transferências permitem que o usuário localize probabilisticamente a causa raiz de um erro. Por exemplo, se transferirmos entre as atividades M e N, respectivamente, nos componentes M e N, e uma falha acontecer em N logo após a transferência de volta para M, podemos concluir que é provável que seja devido à passagem de dados de N de volta para M.

Um traço de transferência é emitido da atividade M para a atividade N quando há um fluxo de controle entre M e N. Por exemplo, N executa algum trabalho para M devido a uma chamada de método que cruza os limites das atividades. N pode já existir ou ter sido criado. N é gerado por M quando N é uma nova atividade que realiza algum trabalho para M.

Uma transferência de M para N não pode ser seguida por uma transferência de volta de N para M. Isso ocorre porque M pode gerar algum trabalho em N e não rastrear quando N conclui esse trabalho. Na verdade, M pode terminar antes de N concluir sua tarefa. Isso acontece na atividade "Open ServiceHost" (M) que gera atividades de ouvinte (N) e, em seguida, termina. Uma transferência de volta de N para M significa que N concluiu o trabalho relacionado com M.

N pode continuar executando outro processamento não relacionado a M, por exemplo, uma atividade de autenticador existente (N) que continua recebendo solicitações de login (M) de diferentes atividades de login.

Não existe necessariamente uma relação de aninhamento entre as atividades M e N. Isto pode acontecer por dois motivos. Primeiro, quando a atividade M não monitora o processamento real realizado em N, embora M tenha iniciado N. Segundo, quando N já existe.

Exemplo de Transferências

A seguir estão listados dois exemplos de transferência.

  • Quando você cria um host de serviço, o construtor ganha controle do código de chamada ou o código de chamada é transferido para o construtor. Quando termina a execução, o construtor devolve o controlo ao código de chamada, ou transfere-o de volta para o código de chamada. Este é o caso de uma relação aninhada.

  • Quando um ouvinte começa a processar dados de transporte, ele cria um novo thread e entrega à atividade Receber Bytes o contexto apropriado para processar, passar controle e dados. Quando esse thread terminar de processar a solicitação, a atividade Receber Bytes não passa nada de volta para o ouvinte. Neste caso, temos uma transferência para dentro, mas nenhuma transferência para fora da nova atividade de thread. As duas atividades estão relacionadas, mas não inseridas.

Sequência de transferência de atividade

Uma sequência de transferência de atividade bem formada inclui as seguintes etapas.

  1. Inicie uma nova atividade, que consiste em selecionar um novo gAId.

  2. Emita um rasto de transferência para esse novo gAId a partir do atual ID de atividade

  3. Definir a nova ID em TLS

  4. Emita um rasto inicial indicando o início da nova atividade.

  5. O retorno à atividade original consiste no seguinte:

  6. Emitir um traço de transferência para o gAId original

  7. Emita um Stop trace para indicar o final da nova atividade

  8. Defina TLS para o gAId antigo.

O exemplo de código a seguir demonstra como fazer isso. Este exemplo pressupõe que uma chamada de bloqueio é feita ao transferir para a nova atividade e inclui rastreamentos de suspensão/retomada.

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

Ver também

  • Last updated on