Es gab keinen Endpunkt, der auf net.pipe empfangsbereit war: // localhost/

Question

Ich habe zwei WCF-Dienste in einem einzigen Windows-Dienst auf einem Windows Server 2003-Computer gehostet. Wenn der Windows-Dienst auf einen der WCF-Dienste zugreifen muss (z. B. wenn ein zeitgesteuertes Ereignis auftritt), wird einer der fünf angegebenen Endpunkte für Namepipes verwendet (unterschiedliche Dienstverträge). Der Dienst stellt auch HTTP MetadataExchange-Endpunkte für jeden der beiden Dienste und net.tcp-Endpunkte für externe Server-Benutzer bereit.

der Regel die Dinge funktionieren gut, aber jeder einmal in eine Weile Ich erhalte eine Fehlermeldung, die etwa wie folgt aussieht:

System.ServiceModel.EndpointNotFoundException: Es gibt keinen Endpunkt war bei net.pipe hören: // localhost/IPDailyProcessing, das die Nachricht annehmen könnte. Dies wird oft durch eine falsche Adresse oder eine falsche SOAP-Aktion verursacht. Weitere Informationen finden Sie unter InnerException, falls vorhanden. ---> System.IO.PipeException: Der Pipe-Endpunkt 'net.pipe: // localhost/IPDailyProcessing' wurde auf Ihrem lokalen Rechner nicht gefunden. --- Ende der Ausnahmestapelüberwachung --- Server Stapelüberwachung: bei System.ServiceModel.Channels.PipeConnectionInitiator.GetPipeName (Uri uri) bei System.ServiceModel.Channels.NamedPipeConnectionPoolRegistry.NamedPipeConnectionPool.GetPoolKey (EndpointAddress Adresse Uri über,) bei System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection (Timespan timeout) bei System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen (Timespan timeout) bei System.ServiceModel.Channels.CommunicationObject.Open (Timespan timeout) bei System.ServiceModel.Channels.ServiceChannel.OnOpen (TimeSpan-Timeout) bei System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan-Timeout) bei System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System.ServiceModel.Channels.ServiceChannel.ICallOnce.Call (ServiceChannel Kanal, Span timeout) bei System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce (Timespan-Timeout, CallOnceManager Kaskade) bei System.ServiceModel.Channels.ServiceChannel.EnsureOpened (TimeSpan Timeout) bei System.ServiceModel.Channels.ServiceChannel.Call (Zeichenfolge Aktion, Boolean Oneway, ProxyOperationRuntime Operation, Objekt [] ins, Objekt [] outs, TimeSpan Timeout) bei System.ServiceModel.Channels.ServiceChannel.Call (String-Aktion, Boolean oneway, ProxyOperationRuntime-Vorgang, Objekt [] ins, Objekt [] outs) bei System.ServiceModel.Channels.ServiceChannelProxy.InvokeService (IMethodCallMessage-MethodeCall, ProxyOperationRuntime-Vorgang) bei System.ServiceModel.Channels.ServiceChannelProxy.Invoke (IMessage Nachricht)

Es ist nicht zuverlässig geschieht, die aufreizend ist, weil ich es nicht wiederholen kann, wenn ich will. In meinem Windows-Dienst habe ich auch einige zeitgesteuerte Ereignisse und einige Datei-Listener, aber das sind ziemlich seltene Ereignisse. Hat jemand irgendwelche Ideen, warum ich auf ein Problem stoßen könnte? Jede Hilfe würde sehr geschätzt werden.

Answer 1

Ich bin mir nicht sicher, ob dies für Ihre Diskussion relevant ist, weil ich nie die .net Named Pipes verwendet habe, aber ich erinnere mich, dass die .net TCP Socket Endpoints einen bekannten Bug hatten, der gelegentlich zu Endpoints führte aus keinem ersichtlichen Grund beendet wurde ", und leider war die offizielle MS-Antwort eine" Problemumgehung ", bei der überprüft wurde, ob der Socket noch aktiv war, bevor eine Nachricht gesendet wurde, und im Falle, dass dies nicht der Fall war. Ich würde gerne denken, dass die benannten Pipe-Endpunkte nicht so unzuverlässig sind wie die "zuverlässigen TCP-Endpunkte", aber Sie sollten vielleicht in den "bekannten periodischen TCP-Socket-Fehler" schauen, um zu sehen, ob er auch Named Pipes umfasst.

Sorry, dass dies nicht wirklich eine Antwort ist, und ich hasse es zu empfehlen, dass Sie die Ineffizienz der Überprüfung hinzufügen müssen, um sicherzustellen, dass es vor dem Senden einer Nachricht usw. ist.

Answer 2

Überprüfen Sie, ob der Dienst "Net.Pipe Listener Adapter" in der Dienstverwaltungskonsole ausgeführt wird. Dies wird von WAS verwendet, um eine Anforderung für Named Pipe zu empfangen.

Answer 3

Ich habe einen ähnlichen Fehler in der Vergangenheit, und wenn ich mich recht erinnere, war es etwas falsch mit den Daten an/von Service übergeben. In meinem Fall war das Problem in der Datengröße (Ich habe die WSHttpBinding verwendet, also gibt es eine HTTP-Standardgrenze). Die Art und Weise, wie ich das Problem fand, war das Hinzufügen von Logging verwandten Methoden, finden Sie die problematischen Daten und versuchen, das Problem in einigen Debug-freundliche Umgebung zu reproduzieren und es passieren (Absturz) ständig mit Daten, die Sie gefunden haben.

In meinem Fall war die Ausnahmebedingungsnachricht nicht mit dem Problem verbunden, das manchmal in WCF passiert.