How should I handle exceptions thrown from one of a collection of WCF callback interface objects?

Question

UPDATE: Since writing this question, I have come across this Bug Report which provides a method of replicating the symptoms of the bug I am seeing consistently.

I cannot, yet, confirm if this is the cause of the bug I am experiencing, but it warrants some investigation. I have not come across a work-around for the bug described in the report yet.

To summarise the report: If the WCF client closes during authentication at the WCF service then an asynchronous exception is thrown at the service, which (in my case) is not caught until it reaches the program.cs file and so makes it difficult to handle gracefully.

Original Question:

I have a WCF Service hosted within a Windows Service.

The WCF service allows clients to subscribe (providing a callback), after which, the service publishes updates to all subscribers.

The service maintains a Dictionary<int, ICallback> of all current subscribers' callback interfaces.

When an event occurs requiring information to be published, the service loops through the collection and calls the appropriate method defined in ICallback.

This all works fine and all occasions where the ICallback objects are used are wrapped in a try catch in case of object disposed exceptions and any other exceptions which might occur.

The problem I am having is that a Communication Exception is being raised at the Service:

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.IO.IOException: The read operation failed, see inner exception.

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 existing connection was forcibly closed by the remote host

This exception is not being caught and is causing the application to crash.

Because it is not being caught, I am assuming that the exception is not being thrown during a time when the service is attempting to publish data because this always occurs within a try - catch.

Could this exception be caused by the client application closing the channel/socket incorrectly?

More importantly, how is it possible to catch an exception raised in this way when the object from which the exception originates is not currently being accessed within a running thread?

i.e. the ICallback object is sat in a dictionary, not being used, when the exception is thrown - so how do I handle the exception? where do I put the try catch?

WCF Service Subscribe Method

public static int Subscribe()
{
    int id = -1;

    OperationContext currentContext = OperationContext.Current;

    if (currentContext != null)
    {
        ICallback callback = currentContext.GetCallbackChannel<ICallback>();

        if (callback != null)
        {
            id = GetNextId();

            lock (SubscriberLock)
            {
                Subscribers.Add(id, callback);
            }
        }
    }
    return id;
}

The exception is thrown some period of time after the completion of this method.

I don't feel totally happy that I have explained the problem very clearly so please ask for clarification if there is a specific point which isn't very clear.

Thanks!

First, you could take a look to WCF diagnostic :http://msdn.microsoft.com/en-us/library/ms733025.aspx. You may get more intel on the exception. — Vivien Ruiz, Jul 02 '12 at 12:20
To catch unhandled exceptions generally, since you didn't specify: for winforms: http://stackoverflow.com/questions/2770/global-exception-handling-for-winforms-control , WPF: http://www.codeproject.com/Articles/90866/Unhandled-Exception-Handler-For-WPF-Applications , Silverlight: http://msdn.microsoft.com/en-us/library/system.windows.application.unhandledexception%28VS.95%29.aspx — Chris Sinclair, Jul 02 '12 at 12:26
@ChrisSinclair - Thanks Chris, I am following this pattern already. This allows me to log the exception at the program.cs file level - but that is a little too late for me to perform any useful clean up tasks or manage the exception in such a way that will allow the application to continue running. — Lewray, Jul 02 '12 at 13:44

score 0 · Answer 1 · edited May 23 '17 at 12:20

0

The communication exception would be thrown at client side, rather than on WCF side. You could catch the communication exception there at client side by wrapping it inside try and catch. CommunicationException is the base type of all the exception generated at wcf. You should also add logging to your wcf service and client. Details of how to add logging here.

edited May 23 '17 at 12:20

Community

1
1

answered Jul 02 '12 at 13:10

Anand

14,545
8
32
44

Hi Anand, thanks for your answer. Both the client and service are using WCF but I assume you mean the Service side instead of WCF side. The Communication Exception I quoted in my question was copied and pasted from the Service log file, not the client. I am working on finding a way to reproduce the error and then will attempt to implement the tracing you suggest in your link. – Lewray Jul 02 '12 at 14:04
Yes, I meant the service side. Have you done any kind of logging, exception handling at client side ? – Anand Jul 02 '12 at 14:06
Yes - I cannot get access to the client log file at the moment. The error does not interrupt the operation of the client application at all though - it continues to run as normal (suggesting that if an exception is thrown at this end, that it is handled appropriately). – Lewray Jul 02 '12 at 14:10

How should I handle exceptions thrown from one of a collection of WCF callback interface objects?

1 Answers1