2010-10-01 11 views
5

Ho un semplice servizio WCF che sto comunicando con Asincrono.Collegamenti WCF che superano le connessioni massime quando si utilizza il modello asincrono

La cosa che non mi piace è quando si chiama il EndServiceMethod(IASyncResult)

se mi dimentico di chiamare il metodo Close(), il servizio sarà effettivamente lasciare la connessione aperta e quindi tutte le connessioni rimanenti fallirà dopo la WCF raggiunge il suo massimo le connessioni contemporanee contano con le eccezioni di timeout.

Ho provato a utilizzare l'attributo al contratto di servizio, che non sembra avere alcun effetto sullo stato della connessione dal servizio.

Forse l'ho implementato in modo errato?

Qualsiasi idea o suggerimento.

Sto cercando di individuare un modello di comportamento per WCF che consenta ai client di effettuare una richiesta, quindi al server di rispondere alla richiesta e quindi di presumere che la connessione sia finita e possa essere interrotta.

risposta

4

Questo è in realtà un problema complicato.

Da un lato se non si chiude il collegamento rimarrà aperto fino a quando non scade (1 min), sotto carico si colpiranno le connessioni massime (default 10).

D'altra parte si stanno chiamando i servizi in modo asincrono, quindi se si chiude la connessione prima che venga ricevuta la richiamata, la callback andrà persa.

ci sono alcune cose che si potrebbe provare:

  • aumentare i collegamenti max
  • chiudere la connessione nel gestore di callback
  • ridurre la lunghezza del timeout
+0

sono stato chiudendola nel gestore di callback e che sembra funzionare. Immagino che stavo solo sperando in una soluzione più elegante che permetta questo lavoro sul lato server. – Beta033

+0

Questa è in realtà la soluzione migliore. A seconda del tuo codice potresti essere in grado di contare il numero di gestori di callback e il numero di volte che hai chiamato chiudi e vedere se corrispondono. –

+0

Tranne che avrò molti client ciascuno con possibilmente con più connessioni. come fanno i servizi pubblici di wcf? Non posso immaginare che si aspettino che i loro clienti siano sempre bravi a chiudere le connessioni quando hanno finito. – Beta033

0

I non so se questo aiuta:

È possibile impostare la rilegatura in modo che

  • Security è impostata su Nessuno
  • sessioni affidabili sono disabilitate

    <wsHttpBinding> 
         <binding name="MyWsHttpBinding"> 
          <reliableSession enabled="false"/> 
          <security mode="None" /> 
         </binding> 
        </wsHttpBinding> 
    

ho scoperto che in questo modo posso aprire un numero illimitato di canali e "dimenticare" per chiudili.

Quindi devi chiedere se è una configurazione accettabile per le circostanze.

0

Chiudere qualsiasi tipo di connessione quando non ne hai più bisogno è solo una responsabilità di base dello sviluppatore. Non c'è nulla di cui lamentarsi. Chiudi la connessione e non avrai questo problema. Cercare di risolvere le chiamate Chiudi mancanti in un altro modo è una sciocchezza.

+0

penso che ti manchi il punto. il punto era consentire al server di gestirlo e non costringere il cliente a mantenerlo. in questo modo, gli errori di comunicazione catastrofici non lascerebbero la connessione aperta sul server e occuperebbero uno slot. – Beta033

+0

No, non lo sono. Le chiamate asincrone non sostituiscono le esigenze di chiusura della connessione. Btw. hai detto che l'istanza di PerCall non funziona per te. Quale legame stai usando? L'istanza di PerCall funziona solo con l'associazione che non usa la sessione di trasporto, affidabile o di sicurezza. –

0

Non utilizzerei il modello asincrono con WCF.Invece, userei solo le chiamate sincrone con i normali blocchi usando per assicurare che la connessione sia chiusa. Quindi vorrei avvolgere tutto il casino in un normale oggetto di lavoro Task (.NET 4.0) o ThreadPool.

+0

Sto iniziando a convincermi che l'utilizzo delle chiamate wcf di sincronizzazione racchiuse in un thread di lavoro sarà il modo di simulare le comunicazioni asincrone. Grazie. – Beta033

Problemi correlati