Я прошу прощения, если это кажется немного базовым, но я новичок в WCF - а также для межпроцессного взаимодействия в целом.
Подробная информация о моей настройке
Я использую NetNamedPipeBindingв моем "сервере" WCF, который является частью приложения, работающего в качестве службы Windows.
У меня есть два клиента, которые взаимодействуют с сервером WCF, используя канал, созданный DuplexChannelFactory.Одним из них является веб-приложение ASP.Net MVC 3, которое создает канал (а затем закрывает его **) при каждом запросе страницы.Второе - это приложение WPF (используется как своего рода консоль мониторинга / диагностический инструмент для службы).
Все работает нормально - часто в течение недели или более - с большим количеством людей, обращающихся к веб-приложению, нопросто иногда что-то ломается внутри "сервера" WCF, и клиенты начинают сообщать об исключении "Объект связи, System.ServiceModel.Channels.ServiceChannel, не может использоваться для связи, потому что он находится в состоянии Faults" всякий раз, когда они пытаются создать каналproxy.
После сбоя сервера каждая попытка подключения приводит к этой ошибке.Даже новые экземпляры консольного приложения сообщат об этом.Это заставляет меня поверить, что это не проблема на стороне «клиента».
** ПРИМЕЧАНИЕ: Я думаю, канал закрывается при каждом запросе страницы.Он создается как член контроллера MVC, который, насколько мне известно, выпадает из области видимости и удаляется в конце запроса.Возможно, я ошибаюсь?
Вопрос (ы):
Есть ли у кого-нибудь какие-либо предложения о том, где искать, и даже о том, как я могу воспроизвести эту проблему в моей тестовой среде.
Можно ли полностью исключить подобные вещи?Или мне следует прибегнуть к созданию потока внутри «сервера», который каждые несколько минут пытается подключиться к службе именованного канала и перезапустить службу в случае сбоя?
Дополнительная информация
Это может бытьполезно включить код, который я использую (в WCF "Сервер") для прослушивания запросов по именованному каналу
host = new ServiceHost(
this,
new Uri[] {
new Uri("net.pipe://localhost")
}
);
host.AddServiceEndpoint(
typeof(IStationDirectory),
new NetNamedPipeBinding(),
"StationDirectory"
);
host.Open();
/* Some logging code here */
Thread.Sleep(Timeout.Infinite);
Дополнительные вопросы
Если я правильно понимаю каждый NamedPipe "Канал "фактически то же самое, что TCP-соединение (уникальное для каждой пары клиент / сервер).Если я продолжаю видеть ошибку канала с новыми клиентами, то, вероятно, каждый новый канал, который создается клиентами, каким-то образом нарушается с самого начала.Означает ли это, что ошибка находится где-то внутри ServiceHost?Будет ли какая-то польза от перехвата host.Faults здесь?
Обновление разрешения (2013)
Я знаю, что прошло очень много времени с тех пор, как я задал этот вопрос - но я только заметил этов моей истории здесь, на SO, и я подумал, что должен добавить, что Ник ударил ногтем по голове.Я полагаю, что проблема была в размере полезной нагрузки сообщения.В сообщения был включен список объектов «отчета», каждый из которых был связан с предыдущим отчетом.Со временем этот список будет расти.Удаление старых отчетов и сохранение более или менее фиксированного размера сообщений WCF останавливали сбои.Приложение работает очень надежно в течение последних нескольких лет.