Сценарий повторного подключения в дуплексном WCF
У меня есть два приложения, соединенные дуплексным соединением WCF. Я хорошо работаю, пока связь постоянна.
Сейчас я проверяю, как обрабатывать сценарии повторного подключения, когда соединение теряется и оно должно снова подключиться. И я изо всех сил пытаюсь понять, как это работает в WCF.
Насколько я знал, IChannel
расходный материал, но ChannelFactory
дорогой. Поэтому я создаю одну фабрику, а затем канал. Всякий раз, когда я обнаруживаю Closed
или же Faulted
события на канале я try
чтобы закрыть канал, отключите обработчики событий, а затем создайте другой канал.
Но этот подход работает не очень хорошо, потому что иногда DuplexChannelFactory<T>.CreateChannel
также выходит из строя и выдает это исключение:
System.ServiceModel.CommunicationObjectAbortedException occurred
HResult=-2146233087
Message=The communication object, System.ServiceModel.InstanceContext, cannot be used for communication because it has been Aborted.
Как это возможно, что сам завод подвергается такому вине?
Каков правильный подход для обработки отключений / повторных подключений в WCF?
2 ответа
Я бы не сказал, что это правильный путь, но...
Мой подход к обработке отключений / повторных подключений заключается в использовании таймера (на клиенте) для вызова метода "ping" в службе через существующее соединение и повторного создания его при необходимости. Не знаю, есть ли лучший способ, не то чтобы я не выглядел.
Моя проблема заключалась в том, что соединение молча терялось, и клиент заканчивал тем, что слушал тупик и пропускал уведомления.
Пытаюсь ответить на эту часть:
"Как это возможно, что сама фабрика будет повреждена таким образом?"
Если вы размещаете приложение в IIS, ваш пул приложений может быть переработан, что приведет к такому поведению. Вы проверяете журналы, чтобы подтвердить, является ли это основной причиной.