How can I handle a failure when replying in a WCF reliable request reply service method

Question

In reliable request reply I understand that the reply is acknowledged and reliable. If for some reason the reply message continually fails on all 8 attempts (the default number of retries being 8) then the channel will then be faulted.

In the server side service method, I need to take action if the reply fails, but I cannot see how I can achieve this as the service method is unaware of the WCF context.

    /// <summary>
    /// This is my service method, and does the reply in reliable request reply
    /// </summary>
    /// <returns></returns>
    public IModelJob GetNextJob()
    {
        //dequeue the next item if there is any
        var modelJob = _priorityQueue.Dequeue();

        //if all attempts to reply fail (or at least fail to be acknowledged) then when and how do I get a chance to requeue this job?
        return modelJob;

    }

It seems much easier to handle failure when you are the client and calling a service method on the proxy itself, as you can implement your own proxy from ClientBase.

I've read: http://msdn.microsoft.com/en-us/library/aa480191.aspx, and searched about but can find nothing specific.

Answer 1

Think of it in terms of the business operation you are ultimately supporting. If, for example, the service expects a sequence of messages from the client at regular 30 minute intervals, they you may have a requirement (in the business sense) that if a message is not seen for 120 minutes, then the service should notify the administrator. This would be implemented in the business logic that drives your service.

It is not a shortcoming of WCF that you cannot have it throw an exception when it hasn't received a message - how would it know it was supposed to expect one in the first place?

Bear in mind that Reliable Messaging works at a layer below the application, just as TCP retransmissions take place without your HTTP application being aware at all. The fact that at the TCP level there needed to be a retransmission, or several, is not a concern of the recipient, and certainly does not throw exceptions up the protocol stack. Its up to the sender of the data to ultimately detect that the data could not be sent, and do something about it. Or, in the example I gave, for the business logic behind the service to implement the requirement at a business level.

You may be interested in a blog post I wrote about some of the shortcomings of WS-ReliableMessaging.