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.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With