Проблема, заставляющая прокси WCF реагировать на отключение сервиса - PullRequest
2 голосов
/ 11 ноября 2010

У меня есть собственный (универсальный) прокси-класс, который я использую для подключения к своим службам WCF.Одной из функций, которые я хочу предоставить этому классу, является способность «восстанавливаться» после сбоя службы (т. Е. Неисправных каналов связи) и завершения работы.Для этого я получаю ссылку на сервисный канал и подписываюсь на события ICommunicationObject.Closed и ICommunicationObject.Faults.Когда эти события происходят, я запускаю процедуру «восстановления», которая в основном пытается восстановить соединение со службой каждые несколько секунд.Предполагается, что если служба по какой-либо причине станет недоступной, она вскоре снова станет доступной, и клиентское приложение сможет выполнить поиск там, где оно было.

У меня есть две службы.Услуга A требует контракта обратного вызова, а услуга B - нет.Служба A использует дуплексный канал, а служба B - нет.Оба требуют сессий.Сервис A неявно создает сеанс;служба B имеет определенные операции IsInitiating и IsTerminating.Вот (несколько сбивающее с толку) поведение, которое я вижу:

Служба A

  • Изящное завершение -> Событие Faults возникает и может быть обработано прокси, но не событием Closed.
  • «Жесткое» отключение -> то же, что и выше.

Сервис B

  • Изящное отключение - событие не вызывается.
  • «Жесткое» отключение - событие не вызывается.

Обратите внимание, что обе службы используют один и тот же класс прокси.Разница лишь в том, как они инициализируются.Прокси-сервер A использует фабрику дуплексных каналов и, следовательно, должен создать контекст экземпляра, в который передается экземпляр, реализующий контракт обратного вызова службы А.Proxy B просто использует "обычную" фабрику каналов.

Есть идеи?

Большое спасибо, J.

1 Ответ

0 голосов
/ 06 декабря 2010

Поможет ли вам здесь свойство ICommunicationObject.State?Должны возвращаться открытые, закрытые, неисправные, а также переходные состояния открытия и закрытия.Возможно, вы можете проверить это в прокси, прежде чем вызывать какие-либо методы

...