Не было прослушивания конечной точки на net.pipe: // localhost /

Question

У меня есть две службы WCF, размещенные в одной службе Windows на компьютере с Windows Server 2003. Если службе Windows требуется доступ к любой из служб WCF (например, при возникновении события по времени), она использует одну из пяти открытых конечных точек именованных каналов (разные контракты на обслуживание). Служба также предоставляет конечные точки HTTP MetadataExchange для каждой из двух служб и конечные точки net.tcp для потребителей, внешних по отношению к серверу.

Обычно все работает отлично, но время от времени я получаю сообщение об ошибке, которое выглядит примерно так:

System.ServiceModel.EndpointNotFoundException: не было конечной точки, прослушивающей net.pipe: // localhost / IPDailyProcessing, которая могла бы принять сообщение. Это часто вызвано неправильным адресом или действием SOAP. Смотрите InnerException, если имеется, для более подробной информации. ---> System.IO.PipeException: конечная точка канала 'net.pipe: // localhost / IPDailyProcessing' не найдена на вашем локальном компьютере. --- Конец внутренней трассировки стека исключений --- Трассировка стека сервера: в System.ServiceModel.Channels.PipeConnectionInitiator.GetPipeName (Uri uri) в System.ServiceModel.Channels.NamedPipeConnectionPoolRegistry.NamedPipeConnectionPool.GetPoolKey (адрес конечной точки, адрес Uri через) в System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection (время ожидания TimeSpan) в System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen (время ожидания TimeSpan) в System.ServiceModel.Channels.CommunicationObject.Open (время ожидания TimeSpan) в System.ServiceModel.Channels.ServiceChannel.OnOpen (время ожидания TimeSpan) в System.ServiceModel.Channels.CommunicationObject.Open (время ожидания TimeSpan) в System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System.ServiceModel.Channels.ServiceChannel.ICallOnce.Call (канал ServiceChannel, время ожидания TimeSpan) в System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce (время ожидания, каскад CallOnceManager) в System.ServiceModel.Channels.ServiceChannel.EnsureOpened (TimeSpan timeout) в System.ServiceModel.Channels.ServiceChannel.Call (строковое действие, логический односторонний режим, операция ProxyOperationRuntime, Object [] ins, Object [] outs, TimeSpan timeout) в System.ServiceModel.Channels.ServiceChannel.Call (строковое действие, логический односторонний режим, операция ProxyOperationRuntime, Object [] ins, Object [] outs) в System.ServiceModel.Channels.ServiceChannelProxy.InvokeService (метод IMethodCallMessageCall, операция ProxyOperationRuntime) в System.ServiceModel.Channels.ServiceChannelProxy.Invoke (сообщение IMessage)

Это не происходит надежно, что сводит с ума, потому что я не могу повторить это, когда захочу. В моей службе Windows у меня также есть некоторые синхронизированные события и прослушиватели файлов, но это довольно редкие события. У кого-нибудь есть идеи, почему я могу столкнуться с проблемой? Любая помощь будет принята с благодарностью.

Answer 1

Проверьте, запущена ли служба «Адаптер прослушивателя Net.Pipe» в консоли управления службами. Это используется WAS для получения любого запроса по именованному каналу.

Answer 2

В прошлом у меня была похожая ошибка, и, если я правильно помню, это было что-то не так с данными, передаваемыми в / из сервиса. В моем случае проблема была в размере данных (я использовал WSHttpBinding, поэтому существует ограничение http по умолчанию). Я обнаружил, что проблема заключалась в том, чтобы добавить ведение журнала в связанных методах, найти проблемные данные и попытаться воспроизвести проблему в некоторой дружественной к отладке среде и заставить ее постоянно (аварийно завершать работу) с данными, которые вы нашли.

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

Answer 3

Я не уверен, уместно ли это для вашего обсуждения, потому что я никогда не использовал именованные каналы .net, но я помню, что у конечных точек сокета .net tcp была известная ошибка, в результате которой иногда возникали прекращено без видимой причины ", и, к сожалению, официальный ответ MS был" обходным путем ", который включал проверку того, что сокет все еще был активен перед отправкой сообщения через него, и повторное открытие его в случае, если это не так. Я хотел бы думать, что конечные точки именованных каналов не так ненадежны, как «надежные конечные точки TCP», но вы можете изучить «известный периодический сбой сокета TCP», чтобы узнать, распространяется ли он также на именованные каналы.

Извините, что на самом деле это не ответ, и я не хочу предположить, что вам, возможно, придется добавить неэффективность проверки, чтобы убедиться, что она работает перед отправкой сообщения, и так далее.