Unhandled communication exception using duplex channel

Question

I'm using WCF duplex channel for a service-callback interaction and in addition I use another service on a different port. After some time the duplex channel becomes faulted but when I try to use it I get a communication exception (I don't know when the channel becomes faulted and I can't use SessionFaulted event). Receive timeout is inifinite and setTimeout is 30 sec.

The problem is that I can't find a way to handle this exception, there is no stack trace and I can't catch it anywhere.

I used diagnostics/error handling with behaviors extensions to investigate but no luck.

Exception:

2013-12-23 11:00:34,514 ERROR General - An exception was thrown during a service call. 
Details: System.ServiceModel.CommunicationException: The socket connection was aborted. 
This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. 
Local socket timeout was '10675199.02:48:05.4775807'. ---> System.Net.Sockets.SocketException: An established connection was aborted by the software in your host machine
   at System.ServiceModel.Channels.SocketConnection.HandleReceiveAsyncCompleted()
   at System.ServiceModel.Channels.SocketConnection.OnReceiveAsync(Object sender, SocketAsyncEventArgs eventArgs)
   --- End of inner exception stack trace ---
   at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
   at System.ServiceModel.Channels.TransportDuplexSessionChannel.TryReceiveAsyncResult.End(IAsyncResult result, Message& message)
   at System.ServiceModel.Channels.TransportDuplexSessionChannel.EndTryReceive(IAsyncResult result, Message& message)
   at System.ServiceModel.Dispatcher.DuplexChannelBinder.EndTryReceive(IAsyncResult result, RequestContext& requestContext)
   at System.ServiceModel.Dispatcher.ErrorHandlingReceiver.EndTryReceive(IAsyncResult result, RequestContext& requestContext)

Any ideas?

Answer 1

Well after a long research and since I had no other options I've decided to compare the references of the old and new callbacks and replace the old one if they are different.

The other side will close it's side of the connection on receiving the fault.

This is not the best solution since it sort of brakes the communication contract but it does the job.