2013-03-14 9 views
6

Nel mio progetto corrente (intendo "team di progetto") si utilizzano i servizi WCF ospitati su IIS.Il servizio NetTcpActivator (Net.Tcp Listener Adapter) smette di rispondere occasionalmente

Ecco alcuni dettagli tecnici che possono essere importanti:

  1. Usiamo NET 3.5 per i servizi WCF
  2. Usiamo il protocollo di comunicazione net.tcp
  3. Usiamo sia IIS 7 e IIS 7.5 per ospitare questi servizi
  4. usiamo più processi di lavoro IIS su ogni server

Quindi, il problema è - a volte WCF- i servizi diventano non disponibili. Quando proviamo a raggiungere questi servizi WCF otteniamo un errore di timeout. E l'unico modo per ripristinare il funzionamento del servizio WCF è riavviare il servizio Windows NetTcpActivator (Net.Tcp Listener Adapter).

Secondo la teoria del mio collega, questo errore può essere correlato ai problemi descritti in questo articolo KB:

FIX: Smsvchost.exe per il servizio WCF si blocca quando si esegue un .NET Framework 4- servizio WCF basato http://support.microsoft.com/kb/2536618

Secondo questo articolo, SMSvcHost (servizio contenitore che ospita NetTcpActivator e Port servizio di condivisione) riaggancia se non può instradare una richiesta di w3wp (processo di lavoro IIS) in più di 60 secondi (non timeout configurabile). Sfortunatamente, non siamo in grado di trovare il modo di riprodurre questo errore. Ad esempio, abbiamo limitato SMSvcHost a 1 CPU core e 1 thread e le connessioni in sospeso esteso limitano a 1M e lo spingono al 100% di carico della CPU in modalità utente. E non è stato appeso!

A volte i nostri test di carico portano a strani errori, ma quando li interrompiamo, tutti i servizi tornano automaticamente allo stato normale. Ma a volte non un carico pesante potrebbe appendere NetTcpActivator!

Inoltre, vorrei dire che questo non è un nuovo problema. I miei colleghi l'hanno già preso 3 anni fa (vedi questa discussione per ulteriori informazioni http://forums.iis.net/t/1167668.aspx/1/10). E, sfortunatamente, non hanno ottenuto la risposta. Il problema è appena scomparso dopo alcune modifiche alla configurazione! E ora è tornato sul nuovo server.

Apprezzerò molto tutti voi pensieri e idee!

+0

Hai mai risolto questo problema? –

+0

Ho un ticket aperto con Microsoft per quanto riguarda questo. Sono in grado di riprodurre frequentemente, anche se non in modo affidabile. Finora, sembra che non sia lo stesso problema a cui ti sei collegato da quando una correzione è già uscita e i dump della memoria sono diversi. Spero che saremo in grado di ottenere una soluzione e pubblicherò qui l'aggiornamento. –

risposta

0

OK, dopo molte ricerche ho rintracciato la causa del nostro problema. Ci possono essere altri scenari in cui ciò si verifica, ma si spera che questo possa aiutare alcune persone. Microsoft è in procinto di riprodursi nei loro laboratori e alla fine dovrebbe avere una soluzione.

Nel nostro caso, tutti i pianeti dovevano allinearsi. Abbiamo avuto un pool di app .NET 4 integrato per client e server (sul computer dello sviluppatore). Il servizio utilizzava un file di configurazione esterno per i collegamenti (<bindings configSource="serviceModel.bindings.config" />) che era collegato da un altro progetto e copiato al momento della compilazione con un'attività di compilazione personalizzata aggiunta al file .csproj del servizio.

di riprodurre il problema:

  1. Arrestare tutti i servizi SMSvcHost che eseguono (Net.Tcp *, Net.Pipe, Net.Msmq). Il riavvio non funzionerà poiché il processo SMSvcHost non va via.
  2. da Visual Studio, eseguire un Clean per WcfService
  3. Da Esplora risorse, eliminare serviceModel.bindings.config in WcfService
  4. Run iisreset (si libera di w3wp e comincia SMSvcHost servizi - Premere F5 è l'elenco dei servizi per vedere
  5. Build WcfService (copia il file di configurazione collegato)
  6. Passare alla pagina WcfClient, inviare due volte. Se ricevi un errore ogni volta, probabilmente hai il problema. Sulla nostra applicazione principale si stava dando un timeout, nell'app di prova CommunicationObjectFaultedException invece del timeout, ma o va bene.
  7. Arresta i servizi SMSvcHost. Se si è verificato il problema, Event ID 8 per SMSvcHost viene registrato nel registro eventi di sistema.

Non so ancora se w3wp o SMSvcHost è il colpevole. Il punto 3 è fondamentale, anche se non posso ancora spiegare il perché. Se non si elimina il file, tutto va bene. Se modifichi il file (la data di creazione rimane la stessa), tutto va bene. Se si sposta il file XML di configurazione nel file Web.config principale, tutto funziona correttamente. Quando l'attività di compilazione copia il file, la data di creazione viene aggiornata, quindi suppongo che sia in cache in qualche modo e uno dei processi rileva la modifica della data.

Se si riavvia i servizi SMSvcHost (punto, punto di partenza) una o due volte la richiesta del client passerà e da quel momento in poi tutto funzionerà.

Quindi la mia ipotesi per ora è che questo potrebbe essere un problema subito dopo una distribuzione, ma se ci si assicura che tutto sia in esecuzione (e si riavvii i servizi secondo necessità), allora si dovrebbe andare bene. Non puoi anche fare i file esterni/collegati.

Dopo che Microsoft ha rintracciato il problema, spero di avere più informazioni.

Aggiornamento finale Ho dimenticato di tornare a questo prima. Microsoft ha sostanzialmente ammesso che probabilmente aveva un bug ma poiché c'era una soluzione alternativa e aveva speso abbastanza tempo sul ticket lo stavano chiudendo e non stava facendo ulteriori ricerche. Sembra che ci sia un qualche tipo di condizione di competizione quando SMSvcHost si avvia con la seguente configurazione (simile a quello che ho postato in precedenza):

  1. Host WCF in IIS
  2. Usa un non-binding HTTP in modo che SMSvcHost entra in giocare
  3. Usa file di configurazione esterna per attacchi utilizzando configSource

Collegare la configurazione esterna non aveva nulla a che fare con esso. La soluzione alternativa era di non utilizzare configSource che stiamo facendo ora.

+0

Credo che tu abbia ragione, è nella cache. Svuota le tue directory temporanee. Dato che stai ospitando in IIS, suppongo che sia memorizzato nella cache in un'area .Net della cartella Microsoft.NET. Ho avuto un problema simile con un'applicazione web - a meno che non ho eliminato il runtime memorizzato nella cache da quella cartella sembrava avere le informazioni nuove e vecchie insieme e la mia app non funzionava. Non ho mai capito esattamente perché questo comportamento; appena sviluppando ho lavorato intorno ad esso.Ho cancellato il vecchio primo manualmente che è stato un dolore al collo, ma è stato più facile che cercare di risolvere il problema. – Stix