Periodic Exception in WSDL Export Extension

Question

I have a SOAP service that's been running for a little over a month now. Over the past two weeks we've had situations where the service will randomly start to generate exceptions. Each time, they seem to be related to the export extension, and the error is always along the following lines:

An exception was thrown in a call to a WSDL export extension: System.ServiceModel.Description.DataContractSerializerOperationBehavior

With "System.ArgumentException: The named node is from a different document context." seeming to be the root cause each time.

What's bugging me is that this service hasn't changed in a month and a half, so I'm confused how suddenly we'd be getting the argument errors all of a sudden. Is this more indicative of an underlying issue (memory leak or similar)?

I have very limited access to the machine this is running on, but can try and get any supporting information as needed. Here's the full exception the wsdl is coming back with:

    An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
    System.InvalidOperationException: An exception was thrown in a call to a WSDL export extension: System.ServiceModel.Description.DataContractSerializerOperationBehavior
     Endpoint: [endpoint name here... hidden for security] ----> System.ArgumentException: The named node is from a different document context.
       at System.Xml.XmlAttributeCollection.Append(XmlAttribute node)
       at System.ServiceModel.Description.SoapHelper.CreateSoapFaultBinding(String name, WsdlEndpointConversionContext endpointContext, FaultBinding wsdlFaultBinding, Boolean isEncoded)
       at System.ServiceModel.Description.MessageContractExporter.MessageBindingExporter.ExportMessageBinding(OperationDescription operation, Type messageContractExporterType)
       at System.ServiceModel.Description.WsdlExporter.CallExtension(WsdlEndpointConversionContext endpointContext, IWsdlExportExtension extension)
       --- End of inner ExceptionDetail stack trace ---
       at System.ServiceModel.Description.ServiceMetadataBehavior.MetadataExtensionInitializer.GenerateMetadata()
       at System.ServiceModel.Description.ServiceMetadataExtension.EnsureInitialized()
       at System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.InitializationData.InitializeFrom(ServiceMetadataExtension extension)
       at System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.GetInitData()
       at System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.TryHandleMetadataRequest(Message httpGetRequest, String[] queries, Message& replyMessage)
       at System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.ProcessHttpRequest(Message httpGetRequest)
       at SyncInvokeGet(Object , Object[] , Object[] )
       at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
       at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
       at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
       at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc)
       at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)

EDIT: I wanted to clarify that the service doesn't always hit this exception. Sometimes the wsdl comes back fine, other times it throws this exception (I'd say currently it's a 50/50 shot of getting a successful return). I can't make heads or tails as to why. My initial thought goes to an environment problem, but if that's the case, I don't have a clue where to point the hosting team to look.

EDIT 2: Since asking the initial inquiry I've found out that the client has put the services on multiple servers and is using a load balancer, which, I believe, accounts for the random responses we're getting. I've advised them how to proceed in at least isolating the problem and will go from there.

Answer 1

We're also bitten by this, and in our case we're not using WsdlExporter or anything of our own: this just happens on GETting the WSDL URL, causing an HTTP 500 error. Once the problem occurs, it keeps going wrong for us. The problem goes away when recycling the app pool.

This seems to be a bug somewhere in the Microsoft stack; see https://connect.microsoft.com/VisualStudio/feedback/details/428531/wsdl-generation-error for a bug report that is open at Microsoft Connect, which has the following workaround:

Add the following code as first thing to execute in every ApplicationDomain that is hosting WCF services:

var soapHelperType = typeof(System.ServiceModel.Description.IContractBehavior).Assembly.GetType("System.ServiceModel.Description.SoapHelper");
var documentProperty = soapHelperType.GetProperty("Document",
BindingFlags.NonPublic | BindingFlags.Static);
documentProperty.GetValue(null, null);

(Since the product causing this is maintained by a separate team, I have not been able to try and verify this workaround.)

Answer 2

I had a similar error to this. In my case it turned out that an instance call to WsdlExporter.GetGeneratedMetaData() was not thread safe and was being called in a Parallel.Foreach. So adding simple locking resolved the issue.

Answer 3

Is difficult to tell by just looking at that error. it doesn’t look like a communication error, but just in case, make sure you are not using singleton as you may create a bottleneck, Per Call is the default method and it works for most of situations, use singleton only if you specifically need it and wrap logic around to avoid bottlenecks.

It seems the error is serializing the data, so make sure your Data Contracts and Data Members are well defined, avoid using plain objects, use typed objects. Declare Data Members as properties

Hope this helps, Sebastian