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.

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? — Tridus
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. — Zann Anderson

BrandonZeider BrandonZeider · Accepted Answer · 2011-03-28T20:24:47

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.

Handle persistent WCF client entering faulted state

2 Answers