Compartir a través de

Transferencia

En este tema se describe la transferencia en el modelo de seguimiento de actividad de Windows Communication Foundation (WCF).

Definición de transferencia

Las transferencias entre actividades representan relaciones de causalidad entre eventos de las actividades relacionadas dentro de los puntos finales. Dos actividades se relacionan con transferencias cuando el control fluye entre estas actividades, como por ejemplo, una llamada al método que cruza límites de actividad. En WCF, cuando los bytes llegan al servicio, la actividad "Listen At" se transfiere a la actividad "Receive Bytes" donde se crea el objeto del mensaje. Para obtener una lista de escenarios de seguimiento de un extremo a otro, así como su diseño de actividades y seguimientos correspondientes, consulte Escenarios de seguimiento de un extremo a otro.

Para emitir seguimientos de transferencia, use el valor ActivityTracing en el origen de seguimiento, tal y como se muestra en el código de configuración siguiente.

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

Uso de la transferencia para poner en correlación actividades dentro de los puntos de conexión

Las actividades y las transferencias permiten al usuario localizar probabilísticamente la causa principal de un error. Por ejemplo, si transferimos de uno a otro respectivamente entre las actividades M y N en componentes M y N, y se bloquea N justamente antes de realizarse la transferencia a M, podemos sacar la conclusión de que es probable que se deba a que N emita datos a M.

Se emite una traza de transferencia de la actividad M a la actividad N cuando hay un flujo de control entre M y N. Por ejemplo, N realiza algún trabajo para M debido a una llamada de método que atraviesa los límites entre actividades. Es posible que N ya exista o se haya creado. M genera N cuando N es una nueva actividad que realiza algún trabajo para M.

Una transferencia de M a N puede no ir seguida de una transferencia de N a M. Esto se debe a que M puede generar algún trabajo en N y no realizar un seguimiento cuando N completa ese trabajo. De hecho, M puede finalizar antes de que N complete su tarea. Esto sucede en la actividad "Open ServiceHost" (M) que genera actividades de escucha (N) y luego finaliza. Una transferencia de vuelta de N a M significa que N completó el trabajo relacionado con M.

N puede seguir realizando otro procesamiento no relacionado con M, por ejemplo, una actividad de autenticador existente (N) que sigue recibiendo solicitudes de inicio de sesión (M) de diferentes actividades de inicio de sesión.

Una relación de anidamiento no existe necesariamente entre las actividades M y N. Esto puede ocurrir debido a dos razones. En primer lugar, cuando la actividad M no supervisa el procesamiento real realizado en N aunque M inició N. En segundo lugar, cuando ya existe N.

Ejemplo de transferencias

A continuación se enumeran dos ejemplos de transferencia.

  • Al crear un host de servicio, el constructor obtiene el control del código que realiza la llamada o el código de llamada se transfiere al constructor. Cuando el constructor ha terminado de ejecutar, devuelve el control al código de llamada o el constructor transfiere de nuevo al código de llamada. Éste es el caso de una relación anidada.

  • Cuando un agente de escucha empieza a procesar datos de transporte, crea un nuevo subproceso y da a la actividad Recibir Bytes el contexto adecuado para procesar, es decir, pasar control y datos. Cuando ese subproceso ha terminado de procesar la solicitud, la actividad Receive Bytes no devuelve nada al agente de escucha. En este caso, tenemos una transferencia de entrada pero ninguna de salida en la nueva actividad de subproceso. Las dos actividades están relacionadas, pero no incluyen a la otra.

Secuencia de transferencia de actividad

Una secuencia de transferencia de actividad bien formada incluye los pasos siguientes.

  1. Inicie una nueva actividad, que consta de seleccionar un nuevo gAId.

  2. Emitir un seguimiento de transferencia a ese nuevo gAId desde el id. de actividad actual

  3. Establecimiento del nuevo identificador en TLS

  4. Emitir un seguimiento de inicio para indicar el principio de la nueva actividad.

  5. Volver a la actividad original consta de lo siguiente:

  6. Emitir un seguimiento de transferencia al gAId original

  7. Emitir un seguimiento de detención para indicar el fin de la nueva actividad

  8. Establezca TLS en el gAId antiguo.

En el ejemplo de código siguiente se muestra cómo hacerlo. Este ejemplo supone que se realiza una llamada de bloqueo al transferir a la nueva actividad, e incluye seguimientos de suspensión/reanudación.

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

Consulte también