Nessun endpoint in ascolto su net.pipe: // localhost/

Question

Ho due servizi WCF ospitati in un singolo servizio di Windows su un computer Windows Server 2003. Se il servizio di Windows deve accedere a uno dei servizi WCF (come quando si verifica un evento temporizzato), utilizza uno dei cinque endpoint della pipa denominati esposti (contratti di servizio diversi). Il servizio espone anche endpoint HTTP MetadataExchange per ciascuno dei due servizi e endpoint net.tcp per utenti esterni al server.

Di solito le cose funzionano molto bene, ma ogni tanto ricevo un messaggio di errore simile a questa:

System.ServiceModel.EndpointNotFoundException: Non c'era nessun punto finale ascolto a net.pipe: // localhost/IPDailyProcessing che potrebbe accettare il messaggio. Questo è spesso causato da un indirizzo errato o un'azione SOAP. Vedi InnerException, se presente, per maggiori dettagli. ---> System.IO.PipeException: l'endpoint del tubo 'net.pipe: // localhost/IPDailyProcessing' non è stato trovato sul computer locale. --- Fine dell'analisi dello stack eccezione interna --- Server stack trace: a System.ServiceModel.Channels.PipeConnectionInitiator.GetPipeName (Uri uri) a System.ServiceModel.Channels.NamedPipeConnectionPoolRegistry.NamedPipeConnectionPool.GetPoolKey (indirizzo EndpointAddress , Uri via) a System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection (TimeSpan timeout) a System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen (TimeSpan timeout) a System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout) su System.ServiceModel.Channels.ServiceChannel.OnOpen (timeout TimeSpan) su System.ServiceModel.Channels.CommunicationObject.Open (timeout TimeSpan) a System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System.ServiceModel.Channels.ServiceChannel.ICallOnce.Call (canale ServiceChannel, TimeSpan timeout) a System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce (TimeSpan timeout, CallOnceManager cascata) su System.ServiceModel.Channels.ServiceChannel.EnsureOpened (timeout TimeSpan) su System.ServiceModel.Channels.ServiceChannel.Call (azione String, oneway booleana, operazione ProxyOperationRuntime, Object [] ins, Object [] outs, timeout TimeSpan) a System.ServiceModel.Channels.ServiceChannel.Call (Azione stringa, Booleano oneway, Operazione ProxyOperationRuntime, Object [] ins, Object [] outs) su System.ServiceModel.Channels.ServiceChannelProxy.InvokeService (metodo IMethodCallMessageCall, operazione ProxyOperationRuntime) presso System.ServiceModel.Channels.ServiceChannelProxy.Invoke (messaggio IMessage)

Non succede in modo affidabile, che è esasperante perché non riesco a ripeterlo quando voglio. Nel mio servizio Windows ho anche alcuni eventi temporizzati e alcuni listener di file, ma questi sono eventi abbastanza rari. Qualcuno ha qualche idea del perché potrei incontrare un problema? Qualsiasi aiuto sarebbe molto apprezzato.

Answer 1

Non sono sicuro se questo è pertinente alla tua discussione, perché non ho mai usato il .net named pipe, ma ricordo che gli endpoint del socket tcp .net avevano un bug noto che ha provocato "endpoint occasionalmente terminato senza un motivo apparente ", e sfortunatamente la risposta ufficiale di MS è stata una" soluzione alternativa "che implicava il controllo che il socket era ancora attivo prima di inviare un messaggio attraverso di esso e riaprirlo nel caso in cui non lo fosse. Mi piacerebbe pensare che gli endpoint di pipe nominati non siano inaffidabili quanto gli "endpoint TCP affidabili", ma potresti voler esaminare il "noto errore periodico del socket TCP" per vedere se si estende anche a pipe con nome.

Mi spiace che questa non sia davvero una risposta, e odio suggerire che potrebbe essere necessario aggiungere l'inefficienza del controllo per assicurarsi che sia attivo prima di inviare un messaggio, eccetera.

Answer 2

Verificare se il servizio "Net.Pipe Listener Adapter" è in esecuzione nella console di gestione dei servizi. Questo viene utilizzato da WAS per ricevere qualsiasi richiesta sulla named pipe.

Answer 3

Ho avuto un errore simile in passato e, se ricordo bene, era qualcosa di sbagliato con i dati passati al/dal servizio. Nel mio caso il problema era nella dimensione dei dati (ho usato WSHttpBinding, quindi c'è un limite predefinito http). Il modo in cui ho trovato il problema è stato aggiungere il logging nei metodi correlati, trovare i dati problematici e provare a riprodurre il problema in un ambiente debug-friendly e farlo accadere (crash) costantemente con i dati che hai trovato.

Nel mio caso il messaggio di eccezione non era correlato al problema, cosa che a volte accade in WCF.