Периодические исключения в расширении экспорта в WSDL

У меня есть SOAP-сервис, который работает чуть больше месяца. За последние две недели у нас были ситуации, когда служба будет случайным образом генерировать исключения. Каждый раз они, похоже, связаны с расширением экспорта, и ошибка всегда находится в следующих строках:

исключение было вызвано вызовом расширения экспорта WSDL: System.Средство servicemodel.Описание:.DataContractSerializerOperationBehavior

С "Система.Значение имени узла из другого контекста документа.- каждый раз кажется, что это первопричина.

что меня беспокоит, так это то, что эта услуга не изменилась за полтора месяца, поэтому я смущен, как внезапно мы получим ошибки аргументов внезапно. Является ли это более показательным для основной проблемы (утечка памяти или аналогичная)?

У меня очень ограниченный доступ к машине, на которой это работает, но я могу попытаться получить любую вспомогательную информацию по мере необходимости. Вот полное исключение, с которым возвращается 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)

EDIT: я хотел уточнить, что служба не всегда попадает в это исключение. Иногда wsdl возвращается нормально, в других случаях он выбрасывает это исключение (я бы сказал, что в настоящее время это 50/50 выстрел получения успешного возврата). Я не могу понять, почему. Моя первоначальная мысль идет к проблеме окружающей среды, но если это так, у меня нет понятия, куда указать команде хостинга смотреть.

EDIT 2: с момента запроса первоначального запроса я узнал, что клиент разместил службы на нескольких серверах и использует балансировщик нагрузки, который, я считаю, учитывает случайные ответы, которые мы получаем. Я посоветовал им, как действовать, по крайней мере, изолировать проблему и идти оттуда.

3 ответов


трудно сказать, просто глядя на эту ошибку. это не похоже на ошибку связи, но на всякий случай убедитесь, что вы не используете singleton, поскольку вы можете создать узкое место, каждый вызов является методом по умолчанию, и он работает для большинства ситуаций, используйте singleton только если вам это нужно и оберните логику вокруг, чтобы избежать узких мест.

кажется, что ошибка сериализации данных, поэтому убедитесь, что ваши контракты данных и члены данных хорошо определены, избегайте использования простые объекты, используйте типизированные объекты. Объявить члены данных как свойства

надеюсь, это поможет, Себастьян!--1-->


У меня была аналогичная ошибка. В моем случае оказалось, что экземпляр вызывает WsdlExporter.GetGeneratedMetaData () не был потокобезопасным и вызывался параллельно.Инструкция foreach. Поэтому добавление простой блокировки решило проблему.


мы тоже укушенный, и в нашем случае мы не используем WsdlExporter или что - нибудь свое: это просто происходит при получении URL-адреса WSDL, вызывая ошибку HTTP 500. Как только проблема возникает, она продолжает идти не так для нас. Проблема исчезает при утилизации пула приложений.

это похоже на ошибку где-то в стеке Microsoft; см. https://connect.microsoft.com/VisualStudio/feedback/details/428531/wsdl-generation-error для отчета об ошибке, который открыт на Microsoft Connect, который имеет следующий обходной путь:

добавьте следующий код как первое, что нужно выполнить в каждом ApplicationDomain то есть хостинг WCF сервисов:

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

(поскольку продукт, вызывающий это, поддерживается отдельной командой, я не смог попробовать и проверить это обходное решение.)