WCF Named Pipe IO Exception - Труба завершена. (109, 0 × 6d)

111
9

У нас есть служба WCF, которая вызывает запуск нескольких других сервисов по протоколу Net.Pipes при запуске. Вызов возвращает список строк, без Enum или сложных объектов.

Иногда мы получаем следующее исключение.

    System.ServiceModel.CommunicationException: There was an error reading from the pipe: The pipe has been ended. (109, 0x6d). ---> System.IO.IOException: The read operation failed, see inner exception. ---> System.ServiceModel.CommunicationException: There was an error reading from the pipe: The pipe has been ended. (109, 0x6d). ---> System.IO.PipeException: There was an error reading from the pipe: The pipe has been ended. (109, 0x6d).
at System.ServiceModel.Channels.PipeConnection.FinishSyncRead(Boolean traceExceptionsAsErrors)
at System.ServiceModel.Channels.PipeConnection.Read(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout)
--- End of inner exception stack trace ---
at System.ServiceModel.Channels.PipeConnection.Read(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout)
at System.ServiceModel.Channels.ConnectionStream.Read(Byte[] buffer, Int32 offset, Int32 count)
at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)
at System.Net.Security.NegotiateStream.StartFrameHeader(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.NegotiateStream.StartReading(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.NegotiateStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
--- End of inner exception stack trace ---
at System.Net.Security.NegotiateStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.NegotiateStream.Read(Byte[] buffer, Int32 offset, Int32 count)
at System.ServiceModel.Channels.StreamConnection.Read(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout)
--- End of inner exception stack trace ---

Это не происходит каждый раз. Я не мог найти почти никаких ссылок на эту ошибку.

Я хотел бы знать, почему это происходит и как его предотвратить.

спросил(а) 2021-01-14T00:12:29+03:00 1 неделя назад
1
Решение
85

Возможная причина заключается в том, что ваш пул приложений перерабатывается, когда веб-служба пытается выполнить свою работу.

Настройте его для запуска в определенное время:

Откройте диспетчер IIS.

На панели "Соединения" разверните узел сервера и нажмите "Пулы приложений".

На странице "Пулы приложений" выберите пул приложений и нажмите "Переработка" в панели "Действия".

Выберите "Определенное время", а в соответствующем поле введите время, в которое вы хотите, чтобы пул приложений ежедневно перерабатывался. Например, введите 11:30 AM или 11:30 PM.

Другая причина может заключаться в том, что полезная нагрузка вашего сообщения слишком велика. Увеличьте время закрытия соединения как на стороне сервера, так и на стороне клиента. Кстати, тайм-аут может произойти не только из-за размера сообщения, но и из-за того, что система слишком занята (процессор на 100% в течение некоторого времени) или потому, что для запуска службы требуется слишком много времени (в этом случае может помочь предварительная компиляция).

Настройка трассировки для вашего приложения может помочь диагностировать проблему: https://msdn.microsoft.com/en-us/library/ms733025.aspx

ответил(а) 2021-01-14T00:12:29+03:00 1 неделя назад
-7

Почему это происходит?

Как уже говорила ошибка: труба закрыта, прежде чем операция чтения имеет шанс запустить.

Как предотвратить это?

Не закрывайте ручку. Ручку можно закрыть несколькими способами:

    Если вызывается функция Abort(). Если вызывается функция Close(). Если вызывается функция DuplicateAndClose().

ответил(а) 2021-01-14T00:12:29+03:00 1 неделя назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема