2010-09-03 23 views
7

Ho un client/servizio WCF con trasporto net.tcp. Quando accendo il tracciamento WCF sul lato client, vedo i seguenti errori nella traccia (vedi screenshot dal servizio trace viewer). La cosa strana è che WCF sta gestendo e recuperando questo errore e il mio client non riceve alcuna eccezione e continua a funzionare. Questa eccezione si verifica in modo casuale, in modo casuale, ma non su ogni chiamata al metodo web. L'autenticazione del client (Windows XP) è Windows, il servizio è identificato da SPN, i servizi sono auto-ospitati sul servizio Windows dietro un NLB (Windows Server 2003). Qualcuno può spiegarmi cosa sta succedendo qui.Strana eccezione WCF net.tcp

Lo StackTrace eccezione dal xml traccia è:

<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:

+1

Come sfondo, alcuni dei nostri utenti segnalavano molte eccezioni e stavo indagando sul motivo per cui solo alcuni dei PC sembrano averlo. Così ho avviato una traccia di servizio sul mio PC e sono rimasto sorpreso dal fatto che queste eccezioni non sono mai ricevute dal client, mentre la WCF le sta inghiottendo. Sto pensando se questa MessageSecurityException stia alla fine facendo sì che alcuni client ottengano delle vere eccezioni. Alcuni client registrano questa eccezione: Impossibile connettersi a net.tcp: // myservice: 9501/SomeService. Il tentativo di connessione è durato per un periodo di 00: 00: 21.3873440. TCP error code 10060: – softveda

+0

Hai menzionato NLB. Usi sessioni adesive (affinità di sessione)? –

+1

Nessuna affinità di sessione NLB è nessuna nelle regole di porta. Il servizio utilizza un binding personalizzato net.tcp con 2 minuti di idletimeout e 1 min leasetimeout. Tuttavia ho scoperto che stiamo usando persession instancecontextmode accidentalmente perché qualcuno ha pensato che fosse l'impostazione predefinita. Cambierò questo per molto presto. – softveda

risposta

-3

Non sono sicuro che il vero problema potrebbe essere e se è legata allo streaming (io immergersi). In ogni caso puoi provare a rilevare l'eccezione sul lato server e lanciare una CommunicationException.

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

In questo modo il proxy client non deve ignorare l'eccezione e lo stato deve essere "Fault".

Problemi correlati