WSDL 导出扩展中的周期性异常

发布于 2024-11-05 15:52:18 字数 3018 浏览 0 评论 0原文

我的 SOAP 服务已经运行了一个多月了。在过去的两周里,我们遇到了服务随机开始生成异常的情况。每次,它们似乎都与导出扩展有关,并且错误总是如下所示:

调用 WSDL 导出扩展时引发异常:System.ServiceModel.Description.DataContractSerializerOperationBehavior

并显示“System.ArgumentException:指定节点来自不同的文档上下文”。每次似乎都是根本原因。

令我困扰的是,这项服务在一个半月内没有发生任何变化,所以我很困惑我们会突然出现参数错误。这是否更能说明潜在问题(内存泄漏或类似问题)?

我对正在运行的计算机的访问非常有限,但可以尝试根据需要获取任何支持信息。这是 wsdl 返回的完整异常:

    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)

编辑:我想澄清该服务并不总是遇到此异常。有时 wsdl 会正常返回,有时它会抛出此异常(我想说目前成功返回的概率是 50/50)。我无法弄清楚为什么。我最初的想法是环境问题,但如果是这样的话,我不知道该向托管团队指出哪里。

编辑2:自从提出初步询问以来,我发现客户端已将服务放在多个服务器上,并且正在使用负载平衡器,我相信这解释了我们收到的随机响应。我已经建议他们如何继续至少隔离问题,并将从那里开始。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

星星的軌跡 2024-11-12 15:52:18

我有一个类似的错误。就我而言,事实证明对 WsdlExporter.GetGenerateMetaData() 的实例调用不是线程安全的,并且是在 Parallel.Foreach 中调用的。因此添加简单的锁定就解决了这个问题。

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.

攀登最高峰 2024-11-12 15:52:18

我们也被这个问题困扰,在我们的例子中,我们没有使用 WsdlExporter 或我们自己的任何东西:这只是在 GETting WSDL URL 时发生,导致 HTTP 500 错误。一旦问题出现,我们就会一直出错。当回收应用程序池时,问题就消失了。

这似乎是 Microsoft 堆栈中某个地方的错误;请参阅 https://connect.microsoft.com/VisualStudio/feedback/有关在 Microsoft Connect 上打开的错误报告的详细信息/428531/wsdl- Generation-error,该报告具有以下解决方法:

添加以下代码作为在每个 ApplicationDomain 中执行的第一件事
正在托管 WCF 服务:

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

由于导致此问题的产品是由单独的团队维护的,因此我无法尝试并验证此解决方法。)

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.)

没有你我更好 2024-11-12 15:52:18

仅通过查看该错误很难判断。它看起来不像是通信错误,但为了以防万一,请确保您没有使用单例,因为您可能会造成瓶颈,每次调用是默认方法,它适用于大多数情况,仅当您特别需要时才使用单例它并包装逻辑以避免瓶颈。

似乎错误在于序列化数据,因此请确保您的数据协定和数据成员定义良好,避免使用普通对象,而使用类型化对象。将数据成员声明为属性

希望这有帮助,
塞巴斯蒂安

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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文