The communication object cannot be used for communication because it has been Aborted

Question

I have a sample WCF project that reproduce a problem that I have with my real WCF application. You can download the source code of my sample WCF application here

Accoding to the timeouts sets in the code and config files, I don't understand what is appening :

**** Server exception : System.ServiceModel.CommunicationObjectAbortedException: 

The communication object, System.ServiceModel.Security.SecuritySessionServerSettings+SecurityReplySessionChannel, cannot be used for communication because it 
has been Aborted.

   at System.ServiceModel.Channels.CommunicationObject.ThrowIfClosedOrNotOpen()
   at System.ServiceModel.Security.SecuritySessionServerSettings.ServerSecuritySessionChannel.SecureApplicationMessage(Message& message, TimeSpan timeout, SecurityProtocolCorrelationState correlationState)
   at System.ServiceModel.Security.SecuritySessionServerSettings.SecuritySessionRequestContext.OnReply(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.RequestContextBase.Reply(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.RequestContextBase.Reply(Message message)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.Reply(MessageRpc& rpc)

**** client exception : : System.ServiceModel.Security.MessageSecurityException: An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail. ---> System.ServiceModel.FaultException: The message could not be processed. This is most likely because the action 'http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Cancel' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding.
   --- End of inner exception stack trace ---

Server stack trace: 
   at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.ProcessRequestContext(RequestContext requestContext, TimeSpan timeout, SecurityProtocolCorrelationState correlationState)
   at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.ReceiveInternal(TimeSpan timeout, SecurityProtocolCorrelationState correlationState)
   at System.ServiceModel.Security.SecuritySessionClientSettings`1.SecurityRequestSessionChannel.CloseOutputSession(TimeSpan timeout)
   at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.CloseSession(TimeSpan timeout, Boolean& wasAborted)
   at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.OnClose(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.OnClose(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
   at System.ServiceModel.ClientBase`1.System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
   at System.ServiceModel.ClientBase`1.Close()
   at System.ServiceModel.ClientBase`1.System.IDisposable.Dispose()
   at WindowsFormsApplication1.Program.Main() in C:\Users\sdoucet\Documents\Visual Studio 2008\Projects\TestWCFLongExecution\WindowsFormsApplication1\Program.cs:line 25

Answer 1

We had a similar issue because the application pool hosting the service was configured to have Maximum Worker Processes greater than 1. For a call to Abort or Close to succeed, it needs to be routed to the same service instance that handled the original request.

Answer 2

Looks like you are passing exceptions back to the client. WCF doesn't like regular exceptions, it wants fauls or a FaultException in case of errors. After and exception has been returned the channel is in a faulted state and cannot be used again. After a FaultException the channel is still usable.

Answer 3

I had a similar issue where I made a wcf service async call. After receiving the result in the async_completed method I got an exception.

"An exception occurred during the operation, making the result invalid. Check InnerException for exception"

InnerException:
"The communication object cannot be used for communication because it has been Aborted"

After a lot of effort I find the solution, just catch the exception without throwing in the async_completed method. (i.e. implemented the try/catch). I didn't understand what is the exact problem, but somehow communication channel is breaking.

I tried the above approch from the following link

http://geekswithblogs.net/SoftwareDoneRight/archive/2008/05/23/clean-up-wcf-clients--the-right-way.aspx

Still I am not confident that this is the right approach, but as per my scenario with the operation result I am not doing anything furtherly. So it is catching exception and stopping the service.