2015-06-11 32 views
6

Sto utilizzando il servizio WCF sincrono che funziona bene il 99% delle volte, ma in alcune rare occasioni il client va in timeout prima che il server termini l'elaborazione. C'è un modo per rilevare, sul lato SERVER, che il client è scaduto? Potrei usare l'operazione asincrona, ma in questo caso il rilevamento del timeout sul lato server mi farebbe risparmiare un bel po 'di lavoro. Sto usando il binding net.tcp, se questo è importante.Come rilevare l'eccezione di timeout del client sul lato server?

+0

Async non cambierebbe il modo in cui funzionano i timeout. – usr

+0

Le operazioni asincrone WCF non hanno valori di ritorno e non aspettano che l'operazione venga completata sul lato server. I miei timeout si verificano a causa dell'elaborazione (occasionale) sul lato server, senza problemi di rete. Pertanto l'operazione asincrona risolverebbe questo problema, ma sto cercando una soluzione diversa. –

+0

Quando si dice WCF asincrona, si sta parlando di "async/await', o dei contratti di operazione OneWay? Dal tuo commento, sembra un'operazione OneWay. Per quanto riguarda il rilevamento del timeout sul client, non sono sicuro che potresti farlo, dal momento che è sul lato client. Il server dovrebbe avere modo di interrogare il client per vedere se era ancora attivo, forse un collegamento duplex. – Tim

risposta

1

Per net.tcp, http, ecc. In generale n. (vedere i commenti sopra per alcune idee, potrebbe anche essere diverso per altri protocolli/collegamenti/ecc.)

Il motivo è che il codice dell'infrastruttura WCF sul lato server non utilizzerà il canale prima di aver completato l'esecuzione del il codice di implementazione dell'operazione di servizio e il marshalling della risposta. Solo allora tenterà di inviare la risposta e a questo punto riconosce che la connessione è già stata interrotta dal client.

Quando il server riceve questo errore, il codice utente (l'implementazione dell'operazione di servizio) è già stato eseguito e quindi non è più possibile reagire da lì. Potrebbe essere possibile da un dispatcher o da un altro punto di estensione, ma personalmente non ho provato. Tuttavia, anche questo non salverebbe il tuo server dal lavoro non necessario, perché come detto, la disconnessione del client verrà comunque riconosciuta solo quando il server tenta effettivamente di inviare la risposta.

Un modo "semplice" per mitigare tali problemi potrebbe essere quello di dividere il lavoro in corso in diverse operazioni/chiamate di servizio (se possibile, e non introducendo accidentalmente lo stato lato server nel processo). O come altri hanno detto, il client deve implementare un'interfaccia "Ping" che il server può utilizzare per verificare se il client è ancora "vivo" e la risposta è ancora necessaria.

Problemi correlati