Es wurde kein Endpunkt Zuhören im Netz.pipe://localhost/
Habe ich zwei gehostete WCF-Dienste in einer einzelnen Windows-Dienst auf einem Windows Server 2003-Maschine. Wenn der Windows-Dienst zugreifen muss entweder der WCF-Dienste (wie, wenn ein zeitgesteuertes Ereignis Eintritt), verwendet er eine der fünf named-pipe-Endpunkte (verschiedene service-Verträge). Der service macht auch HTTP-MetadataExchange Endpunkte für jede der beiden Leistungen, und net.tcp-Endpunkte für die Verbraucher außerhalb des Servers.
In der Regel Dinge, die gut funktionieren, aber jeder einmal in eine Weile bekomme ich eine Fehlermeldung, die wie folgt aussieht:
System.ServiceModel.EndpointNotFoundException: Es wurde kein Endpunkt Zuhören im Netz.pipe://localhost/IPDailyProcessing könnte, dass die Nachricht akzeptiert. Dies wird oft verursacht durch eine fehlerhafte Adresse oder SOAP-Aktion. Sehen InnerException, falls vorhanden, für weitere details. ---> System.IO.PipeException: Der pipe-Endpunkt " net.pipe://localhost/IPDailyProcessing' konnte nicht gefunden werden auf Ihrer lokalen Maschine.
--- Ende der inneren Ausnahme-stack-trace - - -Server stack-trace:
System.ServiceModel.- Kanäle.PipeConnectionInitiator.GetPipeName(Uri uri)
System.ServiceModel.- Kanäle.NamedPipeConnectionPoolRegistry.NamedPipeConnectionPool.GetPoolKey(EndpointAddress Adresse, Uri via)
System.ServiceModel.- Kanäle.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)
System.ServiceModel.- Kanäle.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan-timeout)
System.ServiceModel.- Kanäle.CommunicationObject.Open(TimeSpan-timeout)
System.ServiceModel.- Kanäle.ServiceChannel.OnOpen(TimeSpan-timeout)
System.ServiceModel.- Kanäle.CommunicationObject.Open(TimeSpan-timeout)
bei System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System.ServiceModel.Channels.ServiceChannel.ICallOnce.Call(ServiceChannel channel, TimeSpan timeout)
System.ServiceModel.- Kanäle.ServiceChannel.CallOnceManager.CallOnce(TimeSpan timeout, CallOnceManager cascade)
System.ServiceModel.- Kanäle.ServiceChannel.EnsureOpened(TimeSpan-timeout)
System.ServiceModel.- Kanäle.ServiceChannel.Call(String Aktion, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
System.ServiceModel.- Kanäle.ServiceChannel.Call(String Aktion, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
System.ServiceModel.- Kanäle.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime Betrieb)
System.ServiceModel.- Kanäle.ServiceChannelProxy.Invoke(IMessage message)
Es klappt nicht zuverlässig, das ist zum Verrücktwerden, denn ich kann das nicht wiederholen, wenn ich möchte. In meinem windows-Dienst habe ich auch eine zeitgesteuerte Ereignisse und manche Datei-Hörer, aber diese sind relativ seltene Ereignisse. Hat jemand irgendwelche Ideen, warum ich vielleicht ein Problem Auftritt? Jegliche Hilfe würde sehr geschätzt werden.
InformationsquelleAutor virsum | 2009-08-07
Du musst angemeldet sein, um einen Kommentar abzugeben.
Überprüfen, ob "Net.Pipe Listener Adapter" - Dienst ausgeführt wird in Services management console. Von dieser WURDE erhalten, jede Anfrage auf named pipe.
iisresetauf Ihre festen nichts, Neustarten dieses service +iisresetwurde das Problem behoben.InformationsquelleAutor Suneet Nangia
Ich bin mir nicht sicher, ob das ist relevant für die Diskussion, denn ich habe noch nie verwendet die .net named pipes, aber ich erinnere mich, dass die .net tcp-socket-Endpunkte hatte ein bekannter bug, der dazu geführt in "Endpunkte gelegentlich beendet wird ohne ersichtlichen Grund", und leider ist die offizielle MS Reaktion war ein "workaround", die beteiligten zu prüfen, dass die Buchse war noch bis vor dem senden einer Nachricht über es, und re-opening in dem Fall, dass er es nicht war. Ich würde gerne glauben, dass die named pipe-Endpunkte sind nicht so unzuverlässig, wie die "zuverlässige TCP-Endpunkte", aber möchten Sie vielleicht einen Blick in die "bekannte periodische TCP-socket-Fehler", um zu sehen, ob es erstreckt sich auch auf named pipes.
Sorry, dass dies nicht wirklich eine Antwort, und ich hasse es zu empfehlen, die Sie möglicherweise Hinzugefügt haben, um die Ineffizienz zu überprüfen, um sicherzustellen, dass es vor dem senden einer Nachricht, etcetera.
Dickson: Es ist schon eine Weile her, aber ich werde versuchen Sie zu finden, und fügen Sie Sie hier. Sorry, wenn es eine Weile dauert.
Okay, es stellt sich heraus, dass die Fehler, die wir hatten (die zu der Zeit war nicht zu identifizieren, sich entsprechend) wurde inzwischen isoliert, um socket-Erschöpfung, die ist jetzt besser dokumentiert. So, es sei denn, du bist anstrengend Ihre Steckdosen, bezweifle ich, dass mein Vorschlag passend ist. Du könntest schauen, ob du bist anstrengend Ihre Steckdosen, wenn Sie nicht bereits getan haben.
InformationsquelleAutor David Hagan
Ich habe einen ähnlichen Fehler in der Vergangenheit, und, wenn ich mich Recht erinnere, es war etwas falsch mit der Daten zum/vom Dienst. In meinem Fall problem war in Daten Größe (ich habe die WSHttpBinding, also es ist ein http-Standard-Grenzwert). Die Art, wie ich gefunden, das problem war, fügen Sie die Protokollierung in die dazugehörigen Methoden, finden die problematischen Daten, und versuchen Sie es zum reproduzieren des Problems in einigen debug-freundliche Umgebung und machen Sie es möglich (Absturz) ständig mit Daten, die Sie fand.
In meinem Fall die Ausnahme Nachricht wurde nicht auf das problem beziehen, was irgendwann passiert, in WCF.
InformationsquelleAutor Kamarey