10

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.

Mr Mush
  • 1,538
  • 3
  • 25
  • 38
virsum
  • 243
  • 1
  • 5
  • 16
  • I'm struggling with the same issue, did you ever find a solution? Periodically this error occurs. In some cases the exception is 'The message could not be dispatched because the service at the endpoint address 'net.pipe://localhost/d927b6b5-5994-4bd2-b92a-2fbdbae18d28/SendEmailWorkflow/Creation' is unavailable for the protocol of the address'. The service is not hosted in IIS so that rules out IIS/AppPool resets. – Rohland Jan 10 '11 at 15:24

3 Answers3

7

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.

Suneet Nangia
  • 1,670
  • 1
  • 11
  • 7
  • I also got this error message, using net.pipe hosted under IIS. `iisreset` on its own fixed nothing, restarting this service + `iisreset` fixed the issue. – jasper Aug 02 '13 at 19:55
1

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.

Kamarey
  • 10,832
  • 7
  • 57
  • 70
  • Just saw the questions post date:) Author: If you solved the problem - please post the solution or problem reason. – Kamarey Dec 25 '11 at 22:27
0

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.

David Hagan
  • 155
  • 7
  • Can you provide any links to the "known bug" which you describe and the "official MS response". – Chris Dickson Jan 11 '11 at 15:47
  • @Chris Dickson: It's been a while, but I'll try to find them and add them here. Sorry if it takes a while. – David Hagan Jan 12 '11 at 06:17
  • Okay, it turns out that the bug that we were having (which at the time wasn't identifying itself appropriately) has since been isolated to socket-exhaustion, which is now better documented. So, unless you're exhausting your sockets, I doubt that my suggestion is pertinent. You could look into whether you're exhausting your sockets though, if you haven't already. – David Hagan Jan 12 '11 at 07:43