entendimiento WCF sesión fiable el comportamiento de reintento

Question

Tengo varias preguntas acerca de la fiabilidad de sesiones de WCF fiable:

1. ¿Se WCF re-serializar un mensaje durante un intento de reintento?

   2. Si 1 es correcto, ¿ocurre después de eliminar los parámetros del mensaje o no?
   3. Si 2 es correcto, ¿hay alguna forma de identificar que el mensaje se envió con certeza?

Aún no lo podía descubrir mediante un reflector.

UPD 1: Estoy más interesado en los valores de retorno del servidor. ¿Qué pasa con ellos?

UPD 2: ¿Cuándo se eliminan los parámetros del mensaje (para ser precisos, respuesta del servidor)? ¿Sucede cuando se reciben acks apropiados? Esto es lo que quiero decir con parámetros de disposición:

at MyNamespace.MyReply.Dispose() 
    at System.ServiceModel.Dispatcher.MessageRpc.DisposeParametersCore() 
    at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessageCleanup(MessageRpc& rpc) 
    at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc) 
    at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc) 
    at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet) 
    at System.ServiceModel.Dispatcher.ChannelHandler.DispatchAndReleasePump(RequestContext request, Boolean cleanThread, OperationContext currentOperationContext) 
    at System.ServiceModel.Dispatcher.ChannelHandler.HandleRequest(RequestContext request, OperationContext currentOperationContext) 
    at System.ServiceModel.Dispatcher.ChannelHandler.AsyncMessagePump(IAsyncResult result) 
    at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result) 
    at System.ServiceModel.AsyncResult.Complete(Boolean completedSynchronously) 
    at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result) 
    at System.ServiceModel.AsyncResult.Complete(Boolean completedSynchronously) 
    at System.ServiceModel.Channels.InputQueue`1.AsyncQueueReader.Set(Item item) 
    at System.ServiceModel.Channels.InputQueue`1.Dispatch() 
    at System.ServiceModel.Channels.InputQueueChannel`1.Dispatch() 
    at System.ServiceModel.Channels.ReliableReplySessionChannel.ProcessSequencedMessage(RequestContext context, String action, WsrmSequencedMessageInfo info) 
...stack continues 

que hay que usarla para disponer respuesta del servidor (no tengo otro hilo FOS sobre eso vine a esta solución).

UPD 3: Edición Estoy tratando de resolver es que parece que mi respuesta del servidor es primeros intentos de aplicación dispuestos y luego a serializar. Estoy 99% seguro de que no volveré a usar el mismo objeto en ningún otro lado. StackTraces es bastante feo y grande para publicar aquí.

Answer 1

No, WCF hace no reserialice el mensaje.

Lo que ocurre es esto (simplificado): durante una sesión, cada mensaje que se envía desde el cliente se almacena en el cliente. Por defecto, hay espacio para 32 mensajes (esto puede modificarse y también hay un búfer en el lado del servicio).

El mensaje se envía al servidor y, si funciona bien y se envía, el servidor envía una confirmación y el cliente elimina el mensaje del búfer.

Sin embargo, si el cliente envió el mensaje # 15 y # 16, y luego recibe una confirmación para el # 16 (pero no para el # 15), entonces el mensaje # 15 se reenvía desde el búfer.

Hay bastantes opciones que puede configurar, como si desea o no la entrega ordenada, cuántas veces el cliente debe intentar enviar un mensaje, etc.

Salida esos artículos y blog para más información:

• Introduction to Reliable Messaging with the Windows Communication Foundation
• WCF: Reliable Message Delivery
• How does Reliable Messaging work
• WCF Sessions and Reliable Messaging
• WCF Top To Bottom Screencast; Reliable Messaging

Espero que esto ayude a aclarar las cosas un poco

actualización de las respuestas: tomado del primer artículo (en MSDN) hice referencia:

Si se supone que tiene un patrón comunicación de solicitud/respuesta, la respuesta necesita ser entregado tan confiablemente como y por lo tanto la parte que responde debe implementar un mecanismo iniciador que es muy similar a lo que la parte solicitante implementa para las solicitudes originales. La parte solicitante, a su vez, es jugando el rol de aceptador para las respuestas . Si se pierden las respuestas, deben ser reenviadas por la parte que responde y, por lo tanto, también deben almacenarse en la memoria caché (y reconocidas). Ambos extremos de una sesión de mensajería confiable , por lo tanto, mantienen cachés separados para el mensaje de salida y los mensajes entrantes.

Así que sí, lo mismo se aplica a las respuestas, así - que funciona bien siempre y cuando tenemos una comunicación de dos vías como sobre NetTCP o HTTP - como se menciona en el artículo, se pone un poco más complicado en caso de una operación unidireccional: consulte el artículo para obtener más información.

Marc