没有端点侦听 net.pipe://localhost/

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/1247185/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-03 13:07:30  来源:igfitidea点击:

There was no endpoint listening at net.pipe://localhost/

.netweb-serviceswcfnamed-pipes

提问by virsum

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.

我有两个 WCF 服务托管在 Windows Server 2003 机器上的单个 Windows 服务中。如果 Windows 服务需要访问任一 WCF 服务(例如发生定时事件时),它会使用公开的五个命名管道端点之一(不同的服务协定)。该服务还为这两个服务中的每一个公开 HTTP MetadataExchange 端点,并为服务器外部的使用者公开 net.tcp 端点。

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)
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 address, Uri via) at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout) 在 System.ServiceModel.Channels.ClientFramingDuplexSessionChannel。

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.

它不会可靠地发生,这令人抓狂,因为我无法在我想要的时候重复它。在我的 Windows 服务中,我也有一些定时事件和一些文件侦听器,但这些事件很少发生。有没有人知道为什么我可能会遇到问题?任何帮助将不胜感激。

回答by Suneet Nangia

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.

检查“Net.Pipe Listener Adapter”服务是否在服务管理控制台中运行。WAS 使用它来接收命名管道上的任何请求。

回答by Kamarey

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.

我过去遇到过类似的错误,如果我没记错的话,是传入/传出服务的数据有问题。就我而言,问题在于数据大小(我使用了 WSHttpBinding,因此存在 http 默认限制)。我发现问题的方法是在相关方法中添加日志记录,找到有问题的数据,并尝试在一些调试友好的环境中重现问题并使用您找到的数据不断发生(崩溃)。

In my case the exception message was not related to the problem, which sometime happens in WCF.

在我的情况下,异常消息与问题无关,有时会在 WCF 中发生。

回答by David Hagan

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.

我不确定这是否与您的讨论密切相关,因为我从未使用过 .net 命名管道,但我确实记得 .net tcp 套接字端点有一个已知错误,该错误导致“端点偶尔被终止明显的原因”,不幸的是,官方的 MS 响应是一种“解决方法”,其中涉及在通过它发送消息之前检查套接字是否仍在运行,并在它不是的情况下重新打开它。我认为命名管道端点并不像“可靠 TCP 端点”那样不可靠,但您可能想查看“已知的定期 TCP 套接字故障”以查看它是否也扩展到命名管道。

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.

抱歉,这不是真正的答案,我不想建议您可能必须添加低效率的检查以确保它在发送消息之前已启动,等等。