I have a .NET WCF web service currently running in production right now. I would say 95% of the time it works flawlessly and as intended. However; there are times when I am throwing an exception that says.
CommunicationException:
An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.
I have been looking around online for the cause of this, and it seems like this is happening when an exception is being thrown on the Host Service side, and it is not being handled properly and being passed back to the client. In this case my service is the client and a third party is the Host. I cannot feasibly ask the third party to change their code to handle this better.
Here is the assumption on my part: Once this exception is thrown, it closes the channel between client and host. Because I am not properly disposing of this connection, I have to wait for it to time-out before I can bring it back. This seems to be about 30 seconds, which is slightly too long to expect the users to wait for. I think I have found a possible workaround.
In my currently implementation I am instantiating my client at the start of my program and making it a global resource that can be called anywhere as needed. I am wondering if is better to use an approach like
using(WCFServiceClient client = new WCFServiceClient ())
{
//More codes here
}
and use that at each place that my client needs to communicate to the host. Essentially only having the connection opened when I needed it, and disposing of it right afterward.
The downside here, I would assume, is that there is extra overhead that is going on behind the scenes to open this connection and close it every time. So to me it comes down to whether or not the throughput is high enough to where my process would be effected by waiting for this overhead at each request. Right now I think that there is only about 12 calls to the host a minute, but the catch is they come in groups of three and the three requests all happen in the same second, so this is where the overhead might be the deal breaker.
Does anyone know what the best practice is?
1
So, I’m not sure if what I’m about to tell you is still correct but according to Mark Seeman in his book “Dependency Injection in .NET” he states that:
Although the correct usage pattern concerning ADO.NET connections should be common knowledge, it’s far less known that the same is true for WCF Clients. They should be closed as soon as we’re finished with a particular set of operations on a service.
Based on that view point, I believe you should close your connection after each request.
That being said, you’ve commented that they are always in batches of 3. It could be a worth while exercise introducing a cache/queue into your system where you collect the requests then open your connection, process all entries in the cache/queue, and then close the connection.
This combination of both aspects could give you a solution to your issue, however you could still find that the error occurs if it is generated from the server side. In which case you still need to implement some error handling into it.