Understanding WCF reliable session retry behaviour

Question

Hi, all!

I have several questions about WCF reliable session reliability:

1. Does WCF re-serialize a message during a retry attempt?

   2. If 1 is correct - does it happen after message parameters were disposed or not?
   3. If 2 is correct - is there any way to identify message was sent for sure?

I could not yet figure that out via reflector.

UPD 1: I'm more interested with server return values. What happens to them?

UPD 2: When are message parameters (to be precise - server reply) disposed? Does it happen when appropriate acks are received? Here is what I mean by disposing parameters:

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

I need to use it to dispose server reply (I have another SOF thread on why I came to this solution).

UPD 3: Issue I'm trying to solve is that it seems that my server reply is first disposed and then application attempts to serialize it. I'm 99% sure that I do not reuse same object anywhere else. Stacktraces are pretty ugly and big to post here.

Answer 1

No, WCF does not reserialize the message.

What happens is this (simplified): during a session, each message being sent from the client is being buffered on the client. By default, there is room for 32 messages (this can be tweaked; and there's also a buffer on the service side).

The message is then sent to the server, and if it gets there okay and is dispatched, the server send a confirmation and the client removes the message from the buffer.

However, if the client sent message #15 and #16, and then gets a confirmation for #16 (but not for #15), then message #15 is re-sent from the buffer.

There are quite a few options you can configure, like whether or not you want ordered delivery, how many times the client should retry sending a message and so forth.

Check out those articles and blog post for more information:

• 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

Hope this helps clarify things a bit

UPDATE on responses: taken from the first article (on MSDN) I referenced:

If we assume having a Request/Response communication pattern, the response needs to be delivered just as reliably as the request and therefore the responding party must implement an initiator mechanism that is very similar to what the requesting party implements for the original requests. The requesting party, in turn, is playing the acceptor role for the responses. If responses get lost, they must be resent by the responding party and therefore they must also be cached (and acknowledged). Both ends of a reliable messaging session therefore maintain separate caches for outbound and inbound messages.

So yes, the same applies to the responses, as well - which works fine as long as we have a two-way communication like over NetTCP or HTTP - as mentioned in the article, it gets a bit trickier in case of a one-way operation - see the article for details.

Marc