没有端点在 net.pipe://localhost/ 上监听
我有两个 WCF 服务托管在 Windows Server 2003 计算机上的单个 Windows 服务中。 如果 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（字符串操作、布尔单向、ProxyOperationRuntime 操作、Object[] ins、Object[] outs、TimeSpan 超时） 在 System.ServiceModel.Channels.ServiceChannel.Call（字符串操作，布尔单向，ProxyOperationRuntime 操作，Object[] ins，Object[] outs） 在System.ServiceModel.Channels.ServiceChannelProxy.InvokeService（IMethodCallMessage方法调用，ProxyOperationRuntime操作） 在 System.ServiceModel.Channels.ServiceChannelProxy.Invoke（IMessage 消息）
它的发生并不可靠，这令人抓狂，因为我无法在想要的时候重复它。 在我的 Windows 服务中，我还有一些定时事件和一些文件侦听器，但这些事件相当罕见。 有谁知道我可能遇到问题的原因吗？ 任何帮助将不胜感激。
I have two WCF services hosted in a single Windows Service on a Windows Server 2003 machine. If the Windows service needs to access either of the WCF services (like when a timed event occurs), it uses one of the five named pipe endpoints exposed (different service contracts). The service also exposes HTTP MetadataExchange endpoints for each of the two services, and net.tcp endpoints for consumers external to the server.
Usually things work great, but every once in a while I get an error message that looks something like this:
System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at net.pipe://localhost/IPDailyProcessing that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. ---> System.IO.PipeException: The pipe endpoint 'net.pipe://localhost/IPDailyProcessing' could not be found on your local machine.
--- End of inner exception stack trace ---Server stack trace:
at System.ServiceModel.Channels.PipeConnectionInitiator.GetPipeName(Uri uri)
at System.ServiceModel.Channels.NamedPipeConnectionPoolRegistry.NamedPipeConnectionPool.GetPoolKey(EndpointAddress address, Uri via)
at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)
at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System.ServiceModel.Channels.ServiceChannel.ICallOnce.Call(ServiceChannel channel, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(TimeSpan timeout, CallOnceManager cascade)
at System.ServiceModel.Channels.ServiceChannel.EnsureOpened(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
It doesn't happen reliably, which is maddening because I can't repeat it when I want to. In my windows service I also have some timed events and some file listeners, but these are fairly infrequent events. Does anyone have any ideas why I might be encountering an issue? Any help would be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
检查“Net.Pipe Listener Adapter”服务是否正在服务管理控制台中运行。 WAS 使用它来接收命名管道上的任何请求。
Check if "Net.Pipe Listener Adapter" service is running in Services management console. This is used by WAS to receive any request on named pipe.
我过去也遇到过类似的错误，如果我没记错的话，传递到服务/从服务传递的数据有问题。 就我而言，问题在于数据大小（我使用了 WSHttpBinding，因此存在 http 默认限制）。 我发现问题的方法是在相关方法中添加日志记录，找到有问题的数据，并尝试在一些调试友好的环境中重现问题，并使用您找到的数据不断地使其发生（崩溃）。
就我而言，异常消息与问题无关，这种情况有时会发生在 WCF 中。
I got a similar error in past, and, if I remember right, it was something wrong with the data passed to/from service. In my case problem was in data size (I used the WSHttpBinding, so there is a http default limit). The way I found the problem was to add logging in related methods, find the problematic data, and try to reproduce the problem in some debug-friendly environment and make it happen (crash) constantly with data you found.
In my case the exception message was not related to the problem, which sometime happens in WCF.
我不确定这是否与您的讨论密切相关，因为我从未使用过 .net 命名管道，但我确实记得 .net tcp 套接字端点有一个已知的错误，导致“端点偶尔被终止”明显的原因”，不幸的是，微软的官方回应是一种“解决方法”，其中包括在通过套接字发送消息之前检查套接字是否仍然处于运行状态，如果不是则重新打开它。 我认为命名管道端点并不像“可靠的 TCP 端点”那么不可靠，但您可能需要研究“已知的周期性 TCP 套接字故障”以查看它是否也扩展到命名管道。
抱歉，这并不是一个真正的答案，我不想建议您可能必须添加低效率的检查，以确保在发送消息之前它已启动，等等。
I'm not sure whether this is germane to your discussion, because I've never used the .net named pipes, but I do recall that the .net tcp socket endpoints had a known bug that resulted in "endpoints occasionally being terminated for no apparent reason", and unfortunately the official MS response was a "workaround" which involved checking that the socket was still up before sending a message through it, and re-opening it in the case that it wasn't. I'd like to think that the named pipe endpoints aren't as unreliable as the "reliable TCP endpoints", but you might want to look into the "known periodic TCP socket failure" to see whether it also extends to named pipes.
Sorry that this isn't really an answer, and I hate to suggest that you might have to add the inefficiency of checking to ensure that it's up before sending a message, etcetera.