WCF: Как диагностировать неисправные каналы?
Я работаю над доставкой изменений в моей лаборатории, которые, надеюсь, помогут диагностировать какую-то странную причудливую странность, которую мы наблюдаем. Есть тестовое приложение, которое использует DuplexChannelFactory для подключения к паре оконных сервисов, и по некоторым причинам каналы в этом тестовом приложении, кажется, неисправны. У меня есть планы по внедрению некоторой логики повторов, но было бы здорово выяснить, почему именно они неисправны.
Я знаю, что все фабрики каналов и прокси-объекты реализуют множество интерфейсов, и я использовал отражатель, чтобы пролистать некоторые из них, но я не нашел ничего похожего на то, что я ищу. Есть ли способ запросить эти объекты после их отказа, чтобы получить некоторую информацию о том, что вызвало ошибку?
Редактировать: конфигурация очень проста - привязка - это просто построенная по умолчанию NetTcpBinding, реализация службы имеет [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Reentrant)]и никаких специальных атрибутов нет ни на одной из операций в договоре на обслуживание. Тем не менее, я спрашиваю больше об общих методах диагностики неисправностей каналов, а не диагностики этого конкретного случая. Я не ожидал бы, что особенности конфигурации будут иметь слишком большое влияние на это; если что-нибудь, подробности конфигурации будут возвращены указанной диагностикой, верно?
4 ответа
Ответы Ладислав и Шираз все хорошие, и я дал им +1.
Все, что я могу добавить к ним, это то, что обычно неисправный канал является результатом необработанного исключения на сервере. Когда это происходит, WCF считает, что с сервером что-то принципиально не так, и отказывает каналу, так что он не может быть использован.
Правильный подход - который, я считаю, должен был использоваться по умолчанию и предоставляться бесплатно - для службы перехватить исключение, создать исключение FaultException и вернуть его (см. Этот пример формы http://www.c-sharpcorner.com/UploadFile/ankithakur/ExceptionHandlingWCF12282007072617AM/ExceptionHandlingWCF.aspx)
Причина, по которой WCF не делает по умолчанию, заключается в том, что он меняет контракт и WSDL, поэтому клиент должен получить обновленный WSDL.
Поэтому на вашем месте я бы перехватывал исключения, регистрировал их, а затем возвращал исключение сбоя, и таким образом я бы знал, в чем проблема, и каналы не были сбиты.
Во-первых, это тестовое приложение или конкретные службы, используемые другими клиентами.
Предполагая, что это тестовый клиент, который вызывает проблему. Там может быть 2 проблемы:
- Не закрывает прокси, поэтому максимальное количество подключений к серверу.
- Не прерывать прокси, когда они находятся в состоянии сбоя.
Диагностический инструмент, который вы ищете, называется WCF Tracing. Обычно это показывает, почему канал вышел из строя. Вы можете настроить его как на клиенте, так и на сервере и использовать SvcTraceViewer.exe для просмотра собранных трасс.