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

У меня есть две службы 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(адрес EndpointAddress, Uri via) в 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(тайм-аут TimeSpan, каскад CallOnceManager) в System.ServiceModel.Channels.ServiceChannel.EnsureOpened(тайм-аут TimeSpan) в System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object [] ins, Object [] outs, TimeSpan timeout) в System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object [] ins, Object [] outs) в System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(метод IMethodCallMessageCall, ProxyOperationRuntime) в System.ServiceModel.Channels.ServiceChannelProxy.Invoke(сообщение IMessage)

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

Ответ 1

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

Ответ 2

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

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

Ответ 3

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

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