No se escuchaba ningún punto final en net.pipe: // localhost/

Question

Tengo dos servicios WCF alojados en un solo servicio de Windows en una máquina con Windows Server 2003. Si el servicio de Windows necesita acceder a cualquiera de los servicios de WCF (como cuando se produce un evento programado), utiliza uno de los cinco endpoints de canal con nombre expuestos (diferentes contratos de servicio). El servicio también expone los puntos finales HTTP MetadataExchange para cada uno de los dos servicios, y los puntos finales net.tcp para los consumidores externos al servidor.

Por lo general, las cosas funcionan muy bien, pero de vez en cuando me sale un mensaje de error que se ve algo como esto:

System.ServiceModel.EndpointNotFoundException: No hubo extremo de escucha en net.pipe: // localhost/IPDailyProcessing que podría aceptar el mensaje. Esto a menudo es causado por una dirección incorrecta o acción SOAP. Vea InnerException, si está presente, para más detalles. ---> System.IO.PipeException: el extremo del conducto 'net.pipe: // localhost/IPDailyProcessing' no se pudo encontrar en su máquina local. --- Final de seguimiento de pila de excepción --- servidor de seguimiento de la pila: en System.ServiceModel.Channels.PipeConnectionInitiator.GetPipeName (Uri uri) en System.ServiceModel.Channels.NamedPipeConnectionPoolRegistry.NamedPipeConnectionPool.GetPoolKey (dirección EndpointAddress , Uri vía) en System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection (TimeSpan tiempo de espera) en System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen (TimeSpan tiempo de espera) en System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan tiempo de espera) en System.ServiceModel.Channels.ServiceChannel.OnOpen (TimeSpan timeout) en System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout) en System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System.ServiceModel.Channels.ServiceChannel.ICallOnce.Call (canal ServiceChannel, TimeSpan timeout) en System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce (TimeSpan timeout, CallOnceManager cascade) en System.ServiceModel.Channels.ServiceChannel.EnsureOpened (TimeSpan timeout) en System.ServiceModel.Channels.ServiceChannel.Call (String action, Boolean oneway, ProxyOperationRuntime operation, Object [] ins, Object [] outs, TimeSpan timeout) en System.ServiceModel.Channels.ServiceChannel.Call (String action, Boolean oneway, ProxyOperationRuntime operation, Object [] ins, Object [] outs) en System.ServiceModel.Channels.ServiceChannelProxy.InvokeService (IMethodCallMessage methodCall, ProxyOperationRuntime operation) en System.ServiceModel.Channels.ServiceChannelProxy.Invoke (mensaje de iMessage)

Esto no sucede de forma fiable, que es exasperante porque no puedo repetirlo cuando quiero. En mi servicio de Windows también tengo algunos eventos programados y algunos oyentes de archivos, pero estos son eventos bastante infrecuentes. ¿Alguien tiene alguna idea de por qué podría encontrar un problema? Cualquier ayuda sería muy apreciada.

Answer 1

No estoy seguro de si esto es pertinente para su discusión, porque nunca he usado los conductos con nombre .net, pero recuerdo que los puntos finales del socket .net tcp tenían un error conocido que ocasionaba "puntos finales ocasionalmente finalizado sin ningún motivo aparente ", y desafortunadamente la respuesta oficial de MS fue una" solución "que implicaba verificar que el socket aún estaba activo antes de enviar un mensaje a través de él, y volver a abrirlo en caso de que no lo fuera. Me gustaría pensar que los puntos finales de canalización nombrados no son tan poco confiables como los "puntos finales TCP confiables", pero es posible que desee examinar el "fallo de socket TCP periódico conocido" para ver si también se extiende a canalizaciones con nombre.

Disculpe que esta no es realmente una respuesta, y odio sugerir que podría tener que agregar la ineficacia de la comprobación para asegurarse de que esté activa antes de enviar un mensaje, etcétera.

Answer 2

Compruebe si el servicio "Net.Pipe Listener Adapter" se está ejecutando en la consola de administración de servicios. WAS lo usa para recibir cualquier solicitud en una tubería con nombre.

Answer 3

Recibí un error similar en pasado, y, si mal no recuerdo, hubo algún problema con los datos pasados ​​a/desde el servicio. En mi caso, el problema estaba en el tamaño de los datos (utilicé el WSHttpBinding, por lo que hay un límite predeterminado http). La forma en que encontré el problema fue agregar el registro en métodos relacionados, encontrar los datos problemáticos y tratar de reproducir el problema en un entorno amigable para la depuración y hacer que ocurra (bloqueo) constantemente con los datos que encontraste.

En mi caso, el mensaje de excepción no estaba relacionado con el problema, que en algún momento sucede en WCF.