Трассировка WCF. Как я могу получить точную причину заключительного соединения?
В моем сервисе WCF, при попытке передают большие данные, я постоянно получаю ошибку: базовое соединение было закрыто: соединение было неожиданно закрыто
Я хочу знать, какая конкретная причина вызывает эту ошибку, таким образом, я настроил Трассировку WCF и могу считать traces.svclog файл.
Проблема, что я вижу в этом файле большую информацию о потоке процессов, я вижу точное время, когда исключение появляется, но я не вижу точной причины этого. Действительно ли это происходит из-за MaxReceivedMessageSize или чего-то как этот.
Это так, чтобы traces.svclog не мог содержать такую информацию, или я делаю что-то не так?
Как такая информация могла быть получена?
Отредактированный (добавил):
От моей серверной стороны app.config:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="NAVBinding_ICustomer_Service"
closeTimeout="01:50:00"
openTimeout="01:50:00" receiveTimeout="01:50:00" sendTimeout="01:50:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="2147483647" maxBufferPoolSize="2147483647"
maxReceivedMessageSize="2147483647" messageEncoding="Text"
textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name = "Customer_Service" behaviorConfiguration="returnFaults">
<endpoint name="NAVBinding_ICustomer_Service"
address = "http://localhost:8000/nav/customer"
binding = "basicHttpBinding"
bindingConfiguration= "NAVBinding_ICustomer_Service"
contract = "NAVServiceReference.ICustomer_Service"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="returnFaults" >
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
Отредактированный (добавил):
Что правильный и лучший способ состоит в том, чтобы повернуть сервис WCF от "черного квадрата" до легко расследовавшего сервиса, который говорит причину, почему что-то идет не ожидаемым путем? Какие инструменты, методы Вы используете для поиска и устранения неисправностей сервиса WCF?
4 ответа
Игнорируя проблемы с maxRequestLength (на которые ответили другие), Я отвечу на ваш оригинальный вопрос о том, как устранять неполадки с WCF.
Если вы уже используете просмотрщик Service Trace Viewer (я не смог отличить это по вопросу если бы вы просто просматривали их вручную) - возможно, что все детали не заходя в файл.
Когда я хочу получить действительно хардкор, я включаю все параметры регистрации для запись сообщений. (Это сгенерирует несколько больших служебных журналов, но не оставляйте их. на)
<system.serviceModel>
<diagnostics>
<messageLogging logEntireMessage="true" logMalformedMessages="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" maxMessagesToLog="-1" />
</diagnostics>
</system.serviceModel>
Если вы не используете просмотрщик Microsoft Service Trace Viewer, я рекомендую это сделать. Это . дает всю информацию, которая мне нужна, чтобы отследить это хитрое рукопожатие, сообщение. исключения размеров и т.д. Вот ссылка на MSDN, чтобы вы могли начать. http://msdn.microsoft.com/en-us/library/aa751795.aspx
Следы взаимодействия, которые имеют потенциальные проблемы, подсвечиваются желтым цветом на слева, а подробная панель в верхней правой части обычно поднимает исключительные служебное мероприятие красного цвета. Иногда у вас будут многочисленные проблемы, как внутренние каскады ошибок через сервисный стек - но вы можете видеть все это в trace viewer.
Если вы ничего не получаете в 'service logе' вашего сервера, то возможно, что ваши исключения полностью на стороне клиента - теоретически вы можете превысить часть клиента боковые параметры безопасности (размер сообщения и т.д.) до того, как любое сообщение достигнет значения параметра web-служба - но проблемы клиента, как правило, легче отследить, потому что вы знаете, что вам нужно беспокоиться только о редактировании конфигурационного файла на клиентской стороне (т.е. это не из-за какого-либо взаимодействия между клиентом и настройками сервера)
.Вы должны получить конкретное исключение связи на стороне клиента. Я думаю, что это исключение, которое вы описываете, является исключением, которое возникает после попытки повторно использовать клиент после того, как он отказал.
Попробуйте следующее:
- В файле конфигурации на стороне сервера установите includeExceptionDetailInFaults = "true"
- Когда вы используете клиентскую сторону, не используйте «шаблон использования». Прочтите эту статью
Я не думаю, что вам нужна трассировка. Попробуйте описанное выше, и вы сможете увидеть точную ошибку связи.
О, и, кстати, вашим клиентом является приложение Silverlight? Если так, то все немного сложнее ... Прочтите эту статью.
Попробуйте установить свойство maxRequestLength :
<system.web>
<httpRuntime maxRequestLength="2147483647" />
</system.web>
Чтобы ответить на вопрос, как создать легко запускаемую службой WCF ошибку. Один из способов - минимизировать количество потенциальных ошибок, чтобы при поиске и устранении неисправностей вам было на что посмотреть.
Есть два основных источника ошибок:
- Ошибка из-за конфигурации
- Исключение, брошенное службой WCF
Ошибки в конфигурации часто возникают из-за несовпадения между клиентом и службой. Чтобы избежать этого места, всю конфигурацию можно скопировать в BindingConfiguration и использовать ее как на клиенте, так и на сервере. Я думаю, что на самом деле это то место, где ваша проблема, вы обновляете service web.config, с вещами, которые также должны быть в конфигурации клиента. Для того, чтобы сделать его максимально простым, или иметь буферизацию в одном и потоковую в другом.
Ошибки, брошенные сервисом, должны быть брошены как FaultException и определены в контракте как FaultContract.
Для оставшихся ошибок вам нужно посмотреть в файле trace.svclog, как описано в других постах. Также необходимо просмотреть журнал событий и IIS, вызовы могут быть заблокированы до того, как они достигнут службы WCF.
.