Почему исключение TimeoutException не выдает ошибку на моем канале?

У меня есть дуплексная служба WCF и клиент, работающие на одном компьютере. Клиент настроен на 15-секундные тайм-ауты:

<binding name="NetTcpBinding_IServiceIPC" closeTimeout="00:00:15"
      openTimeout="00:00:15" receiveTimeout="00:00:15" sendTimeout="00:00:15" />

Клиент обрабатывает ошибки следующим образом:

client.InnerChannel.Faulted += FaultHandler;
client.InnerDuplexChannel.Faulted += FaultHandler;
client.ChannelFactory.Faulted += FaultHandler;

Если я убью свой сервисный процесс, клиент правильно получит TimeoutException через 15 секунд:

This request operation sent to net.tcp://localhost:8732/Service/ did not receive a reply within the configured timeout (00:00:15).  The time allotted to this operation may have been a portion of a longer timeout.  This may be because the service is still processing the operation or because the service was unable to send a reply message.  Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client. (System.TimeoutException)

Однако на данный момент канал не поврежден. Мой обработчик ошибок не вызывается примерно через 5 минут после того, как я уничтожу процесс службы. Я думал, что TimeoutException выведет канал из строя (см. этот ответ), но почему-то это не так . Можно ли каким-либо образом ускорить отказ канала после того, как процесс службы будет убит?


person Eric    schedule 15.11.2012    source источник
comment
Кстати, оказалось, что канал не был поврежден, когда моя Служба была убита, потому что Служба запускает несвязанный исполняемый файл, и канал каким-то образом остается открытым, пока этот процесс работает.   -  person Eric    schedule 19.11.2012


Ответы (2)


Этот вопрос Событие Duplex channel Faulted не возникает на вторая попытка подключения предполагает, что событие Faulted не всегда запускается. И диаграмма состояния WCF в MSDN подтверждает эту возможность — http://msdn.microsoft.com/en-us/library/ms789041.aspx

Есть много путей к закрытому состоянию, которые не проходят через неисправное состояние. Скорее всего, по истечении времени ожидания вызывается метод Abort(), и вы переходите из открытого состояния в закрывающееся, минуя состояние сбоя. Добавьте ведение журнала, чтобы проверять состояние во время выполнения. Если вы пытаетесь повторно открыть канал после истечения времени ожидания, это объясняет, почему вы оказываетесь в состоянии сбоя через 5 минут. Чтобы решить более серьезные проблемы, переместите логику в FaultedHandler в другое место, чтобы она выполнялась, когда вы достигаете закрытого состояния другими путями.

person evanmcdonnal    schedule 15.11.2012

Я знаю, что вопрос старый. Но я искал довольно много и всегда оказывался здесь. Поэтому я решил опубликовать свои выводы здесь:

Это зависит от таймаута.

Если вы нажмете SendTimeout или ReceiveTimeout вашей привязки (в моем случае NetTcpBinding), тогда да, канал выйдет из строя.

НО, если вы нажмете OperationTimeout своего Сервиса (в моем случае DuplexChannel), то вы просто получите TimeoutException, и канал НЕ будет ошибаться.

person toATwork    schedule 24.02.2020