Handle persistent WCF client entering faulted state

Question

We've got a WCF service that we're consuming from a web app. The client we're using was generated using the Visual Studio "Add Service Reference" option. Since it's a web app, and since the nature of the app is likely to lead to relatively short sessions, we've opted to create an instance of the client when a user logs in and keep it around for the life of the session, then handle disposing of it when the session is through.

This brings me to my question - we're trying to decide the best way to handle the client's channel entering a Faulted state. After searching around some, we've come up with this:

if(client.State = CommuncationState.Faulted)
{
    client = new Client();
}

try
{
    client.SomeMethod();
}
catch //specific exceptions left out for brevity
{
    //logging or whatever we decide to do
    throw;
}

This, however, does not work due to the fact that, at least in our case, even if the service is down the client will show the Open state until you actually try to make a call using it, at which point it then enters the Faulted state.

So this leaves us to do something else. Another option we came up with was:

try
{
    client.SomeMethod();
}
catch
{
    if(client.State == CommunicationState.Faulted)
    {
        //we know we're faulted, try it again
        client = new Client();
        try
        {
            client.SomeMethod();
        }
        catch
        {
            throw;
        }
    }
    //handle other exceptions
}

But that smells. Obviously, we could avoid this by using a new client and disposing of it for every call. That seems unnecessary, but if it's the right way then I guess that's what we'll opt for. So what is the best way to gracefully handle determining if the client is in a faulted state and then doing something about it? Should we really just be getting a new client for every call?

One other thing to keep in mind - the instantiation of the client and all of this checking and handling happens in a wrapper class for the client. If we do this the way we've intended to, it's transparent to the app itself - making calls and handling exceptions from them requires no special code there.

Injurious

What's causing the client to enter a faulted state? I've always been able to have a WCF service return a fault normally and the client can continue on about it's business. Is the server not responding or something? – Epinephrine

In this case, we're using ASP.NET membership, and we ran into it by exceeding the "userIsOnlineTimeWindow" attribute. Obviously in that case it would make sense to just redirect the user to the login page, but we're trying to make sure we're prepared for any other situation in which we might get into a faulted state. – Injurious

Answer 1

To answer your question, you can handle the Faulted event of the ChannelFactory property like this:

client.ChannelFactory.Faulted += new EventHandler(ChannelFactory_Faulted);

That should allow you to perform whatever logging/cleanup that you need to do.

As a general recommendation, you should not leave the channel open for the duration of the session, so make sure you are closing the channel properly (aborting upon exception) after you're finished with it.

Also, if possible, consider NOT using the Visual Studio Add Service Reference, or at the very least cleaning up the code/config it generates. I recommend that if you want to use a proxy implementation, create your own by deriving from ClientBase, or use a ChannelFactory implementation. Since you mention a wrapper class, I would recommend that you use a ChannelFactory and handle the Faulted event for your cleanup needs.

Evania

Thanks for the answer. I've seen a lot of people talking about opening and closing a client channel for each call and I'm wondering what the reasons are for doing it that way? – Injurious

The reason is that you can only have so many concurrent calls and concurrent sessions to your service. So if every session in your web app has an open session, you will quickly hit the default limit and need to change it, and performance will suffer. Check this out for more information on optimizing these (and other) settings: msdn.microsoft.com/en-us/library/ee377061(v=bts.10).aspx – Evania

Thanks. I've been reading up some more on ChannelFactory and it looks like we'll be moving that direction. – Injurious

@Evania Great find, we're also using a channel factory implementation, I was interested in the reasons why you recommend against using the add service reference. – Yoke

When proxy object goes faulted state method was not calling.. ? – Uncircumcised

Answer 2

Try handling the .Faulted event on the client proxy, eg:

((ICommunicationObject)client).Faulted += new EventHandler(client_Faulted);

private void client_Faulted(object sender, EventArgs e)
{
    client = new Client();
    ((ICommunicationObject)client).Faulted += new EventHandler(client_Faulted);
}

It should trigger the instant the channel faults, giving you a chance to re-open it.

You should still also wrap each call to a client method in a try-catch block, and perhaps even wrap that in a while() loop that retries the call n times, then logs a failure. EG:

bool succeeded = false;
int triesLeft = 3;
while (!succeeded && triesLeft > 0)
{
    triesLeft--;
    try
    {
        client.SomeMethod();
        succeeded = true;
    }
    catch (exception ex)
    {
        logger.Warn("Client call failed, retries left: " + triesLeft;
    }
}
if (!succeeded)
    logger.Error("Could not call web service");

In my code I've gone as far as to use a ManualResetEvent to block the while() loop until the client_Faulted event handler has had a chance to re-create the client proxy.

Lyonnaise

What about unsubscribing from Faulted event? where should it be done? – Harding