Socket connection aborted when calling a WCF service method.

Posted on Posted in Uncategorized

We are cur­rent­ly con­vert­ing our project from .NET Remot­ing to WCF as the pre­ferred method of remote ser­vice calls. One issue we ran into is that some meth­ods worked per­fect­ly while oth­ers bombed with a Com­mu­ni­ca­tionEx­cep­tion with very lit­tle use­ful infor­ma­tion in it. There seemed to be no rhyme or rea­son as to why some meth­ods worked, but oth­ers failed. The excep­tion we always got back on the con­sumer after try­ing to make the ser­vice call was:

The sock­et con­nec­tion was abort­ed. This could be caused by an error pro­cess­ing your mes­sage or a receive time­out being exceed­ed by the remote host, or an under­ly­ing net­work resource issue. Local sock­et time­out was '00:00:59.2350000'.

The var­i­ous lev­els of nest­ed inner excep­tions (the inner­most being "An exist­ing con­nec­tion was forcibly closed by the remote host") were no more help­ful. Fur­ther debug­ging showed that the call did make it from the con­sumer to the ser­vice and that the ser­vice did suc­cess­ful­ly exe­cute the method in under a sec­ond and return the results, so we def­i­nite­ly weren't run­ning into a sock­et time­out. After turn­ing on the trace writ­ers for WCF and dig­ging through the event out­put, we saw issues where some of the types we were return­ing were unrec­og­nized, despite being dec­o­rat­ed with [Dat­a­Con­tract] attrib­ut­es:

Type '(type name)' with data con­tract name '(con­tract name)' is not expect­ed. Add any types not known sta­t­i­cal­ly to the list of known types - for exam­ple, by using the Known­Ty­peAt­tribute attribute or by adding them to the list of known types passed to DataContractSerializer.

In our sce­nario, the cul­prit end­ed up being abstract class­es our objects inher­it­ed. When an object is passed over the wire using WCF, it is instan­ti­at­ed and rehy­drat­ed on the oth­er side. If the type is being passed as an abstract, the con­sum­ing end does not know what con­crete type it should recon­sti­tute the abstract type as. To work around this, you can dec­o­rate the abstract class with the [Known­Type] attribute, spec­i­fy­ing what known con­crete types it could be. Why WCF doesn't auto­mat­i­cal­ly infer this based on both types being [Dat­a­Con­tract]'d, I'm not sure.

For exam­ple, if con­crete type Per­son inher­its abstract type NamedItem­Base and you attempt to call WCF ser­vice method "List<NamedItem­Base> GetAllPeo­ple()", you would need to dec­o­rate your Per­son class with [Dat­a­Con­tract] and your NamedItem­Base with [Dat­a­Con­tract] and [Known­Type(type­of(Per­son))]

Leave a Reply

Your email address will not be published. Required fields are marked *