Extraño WCF net.tcp excepción

Tengo un cliente/servicio WCF con transporte net.tcp. Cuando enciendo el seguimiento de WCF en el lado del cliente, veo los siguientes errores en el rastreo (vea la captura de pantalla del visor de seguimiento del servicio). Lo extraño es que WCF está manejando y recuperando este error y mi cliente no recibe ninguna excepción y continúa funcionando. Esta excepción se produce de manera aleatoria, aleatoria, pero no en todas las llamadas a métodos web. La autenticación del cliente (Windows XP) es Windows, el servicio es identificado por SPN, los servicios son autohospedados en el servicio de Windows detrás de un NLB (Windows Server 2003). ¿Alguien puede explicarme qué está pasando aquí?Extraño WCF net.tcp excepción

El StackTrace excepción de la traza XML es:

<ExceptionString> 
System.ServiceModel.Security.MessageSecurityException: The server rejected the upgrade request. ---&gt; System.ServiceModel.ProtocolException: Error while reading message framing format at position 0 of stream (state: ReadingUpgradeRecord) ---&gt; System.IO.InvalidDataException: More data was expected, but EOF was reached. 
    --- End of inner exception stack trace --- 
    --- End of inner exception stack trace --- 
</ExceptionString>

Screenshot :

Fuente

2010-09-03 softveda

Como contexto, algunos de nuestros usuarios informaron muchas excepciones y yo estaba investigando por qué solo algunas de las PC parecen tenerlo. Así que comencé un seguimiento de servicio en mi propia PC y me sorprendió que el cliente nunca reciba estas excepciones, WCF las está devorando. Estoy pensando si esta MessageSecurityException eventualmente está causando que algunas partes del cliente obtengan excepciones reales. Algunos clientes registran esta excepción: No se pudo conectar a net.tcp: // myservice: 9501/SomeService. El intento de conexión duró un lapso de tiempo de 00: 00: 21.3873440. Código de error TCP 10060: – softveda

Has mencionado NLB. ¿Utiliza sesiones adhesivas (afinidad de sesión)? –

No la afinidad de la sesión NLB no existe en las reglas de puerto. El servicio está utilizando un enlace net.tcp personalizado con 2 minutos de idletimeout y 1 minuto de duración ilimitada. Sin embargo, encontré que estamos usando persession instancecontextmode accidentalmente porque alguien pensó que esto es lo predeterminado. Voy a cambiar esto para percall muy pronto. – softveda

-3

No está seguro de cuál es el problema real podría ser y si está relacionado con el streaming (Voy a bucear en). De todos modos, puede intentar capturar la excepción en el lado del servidor y lanzar una CommunicationException en su lugar.

catch (Exception ex) 
{ 
    throw new CommunicationException(ex.Message, ex); 
}

De esta manera el proxy cliente no debe ignorar la excepción y su estado debe ser "con fallo".

Fuente

2010-09-20 19:04:35

Respuesta

Cuestiones relacionadas