“An existing connection was forcibly closed by the remote host” error in WCF service

For a difference, a post that has nothing to do with SharePoint, but rather with WCF. In my team today, we had a really strange behavior of one of our web services. Everything was ok, except in one method, which was always on the client side throwing the following exception:

“An error occurred while receiving the HTTP response to http://ServiceHost/ServiceName.svc. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.”

Looking at the inner exceptions, two more levels could be noticed:

The underlying connection was closed: An unexpected error occurred on a receive.

and

An existing connection was forcibly closed by the remote host

Googling it didn’t happen too much – some answers were going into direction that complex objects can not be serialized (which is not true, by the way), and other answers were going into direction that the serialized message length was too large, and that the maxRequestLength should be increased in web.config, something like:

<httpRuntime maxRequestLength=”Xyz”…. />

But hey, we were in the test phase, and our serialized messages were really small, this could not be it…

…or wait, could it be?

I looked again on our objects that we are serializing, and saw something like

public class MyClass
{
    public int Id { get; set; }
	
    public string Name { get; set; }
	
    public MyClass Parent { get; set; }
	
    public List<MyClass> Children { get; set; }	
}

OK, that’s it. In an instance of the object, we hold the instance of the parent object, and list of instances of the children objects. And while that’s ok in .NET class, because we are dealing with the “pointers” to the parent and child objects, it looks much different when we serialize it. It serializes the object, then it’s parent object, then the children of the parent object (our starting object is among them), then again the parent… And it serializes infinitely. Until we hit the maximal message size, whatever it would be.

Now, once the problem was diagnosed, the solution was also more than simple – we just put the DataContract attribute on the object, and exclude the “Parent” object property from the contract. Instead, we created a ParentObjectId property, getter only, which only returns the parent’s id.

[DataContract]
public class MyClass
{
    [DataMember]
    public int Id { get; set; }
    
    [DataMember]
    public string Name { get; set; }
    
    //Notice - no [DataMember] here...
    public MyClass Parent { get; set; }
    
    [DataMember]
    public int ParentId 
    {
        get
        {
            return this.Parent.id;
        }
    }
    
    [DataMember]
    public List<MyClass> Children { get; set; }
}

And voila – in the .NET libraries, we can still use the beauty of parent and children collection objects, and when we serialize it, we use the parent ids. Works like a champ. Simple problem, simple solution, but it has caused some thinking on our side.

PS. Btw, don’t you love the WCF Exceptions? They are the only one that compare to SharePoint exception in providing senseful information.