Cosa può causare un ASP.NET processo di lavoro per essere riciclato?

Question

Qui è la mia domanda:

Sto indovinando che il mio problema (descritto di seguito) è causato da ASP.NET i processi di lavoro vengono riciclati, per le categorie sotto—sto usando InProc sessioni di stoccaggio e di non vedere molto la possibilità di allontanarsi, a causa di restrizioni per gli altri tipi di storage che tutti gli oggetti di sessione essere serializzabile.Tuttavia, io non riesco a capire cosa potrebbe rendere il processo di lavoro di essere riciclati, come spesso come lo sto vedendo, non c'era alcuna modifica dei file nella cartella app per quanto ne so, e le opzioni in IIS sembrano implicare che il processo sarebbe solo essere riciclati ogni 1,740 minuti—che è molto meno frequente l'effettiva perdita di sessione.Allora la mia domanda è ora, quali sono i diversi casi può causare un ASP.NET processo di lavoro per essere riciclato?

Ecco la mia domanda originale:

Ho un difficile riprodurre il problema che si verifica nel mio ASP.NET applicazione web.L'applicazione dispone di uno principale .pagina aspx che è caricato e inizializzato un numero di variabili di sessione.Questa pagina utilizza l'ASP.NET Ajax Sys.Net.WebRequest classe ripetutamente di accedere ad un altro .pagina aspx, che utilizza le variabili di sessione per fare le query di database e aggiornare la pagina principale (la pagina principale non è mai ri-richiesto).

Occasionalmente, dopo un periodo di tempo utilizzando la pagina, causando successo le richieste HTTP in cui la sessione creata nella pagina principale correttamente porta con sé la sottopagina, una delle richieste che sembra causare una nuova ASP.NET sessione di creare tutte le variabili di sessione sono perso (causa di un'eccezione nel mio codice), e un nuovo id di sessione viene segnalato in modo dinamico della pagina richiesta.Che significa che improvvisamente, la pagina principale è disconnesso dal server—per quanto riguarda i server, l'utente non è più registrato.

Io sono quasi positivo non è un timeout di sessione—il timeout è impostato su qualcosa di ridicolo, la quantità di tempo necessario per ottenere questo accada è variabile, ma non è mai abbastanza a lungo da causare la sessione di time out, e la costante Sys.Net.WebRequests dovrebbe aggiorna il timer di sessione.

Così, cos'altro potrebbe accadere che possono causare la richieste HTTP per perdere il contatto con la ASP.NET sessione?Io purtroppo non sono stati sniffare il traffico di rete quando questo è successo a me, o io ho controllato se il ASP.NET cookie di sessione è rimasto in giro o meno.

Answer 1

Una soluzione potrebbe essere quella di utilizzare un StateServer, piuttosto che InProc gestione della sessione.

Un sacco di cose che possono causare lo stato della sessione perdute:

1. Web Editing.Config
2. IIS ripristino
3. ecc.

Se lo stato della sessione è importante per la vostra applicazione, utilizzare SQL per la gestione dello stato, o lo Stato del Server che viene fornito con l'ASP.NET.

Ciao

RB.

Answer 2

Abbiamo avuto problemi di Sessione, quando abbiamo fatto la migrazione di AnkerEx applicazione per il nuovo server.Il nuovo server di Microsoft Windows Server 2008 come operazione di sistema e Microsoft Internet Information Services 7.Anche nel server sono stati installati .NET Framework versioni 1.0.3705, 1.1.4322, 2.0.50727, 3.0 e 3.5.Per risolvere questo problema ho fatto l'abilitazione di sorveglianza sanitaria per il applicazione la Vita di eventi correlati ASP.NET 2.0.Avevo aggiunto per il web.config:

...
...
<system.web>
...
...
    <healthMonitoring>
      <rules>
        <add name="Application Events"
            eventName="Application Lifetime Events"
            provider="EventLogProvider"
            profile="Default"
            minInterval="00:01:00" />
      </rules>
    </healthMonitoring>
...
...

È utile per controllare il dominio di applicazione ricicla.Si può vedere presso il nostro Visualizzatore Eventi.Il link per maggiori dettagli http://blogs.msdn.com/rahulso/archive/2006/04/13/575715.aspx

Dopo che ho finito di aggiungere al web.config, il Visualizzatore Eventi mi ha mostrato che il mio applicazione che si sta riavviando ogni volta quando faccio clic per quasi qualsiasi link nella mia applicazione.Dall'articolo di http://blogs.msdn.com/toddca/archive/2005/12/01/499144.aspx io scoperto che ASP.NET è il nuovo comportamento - se faremo l'eliminazione, per esempio una sottodirectory della directory radice dell'applicazione, quindi ASP.NET 2.0 farà il il riavvio del dominio di applicazione.

Il problema era che avevo nel web.config l'istruzione:

...
<compilation debug="true" tempDirectory="c:\AnkerEx\Temporary ASP.NET files">
...

I. e.il ASP.NET ha fatto la compilazione delle pagine aspx nella cartella della mia applicazione principale.Penso che le cartelle create, possono essere e di fatto la rimozione di alcuni di loro anche.Ho rimosso tempDirectory istruzione e l'applicazione inizia il lavoro stabile.

Answer 3

Il processo di lavoro è probabilmente il ciclismo.http://www.lattimore.id.au/2006/06/03/iis-dropping-sessions/

Answer 4

Potrebbe essere causato da un'eccezione non gestita in un thread in background.Esso può causare la ASP.NET processo di lavoro di recedere.Un nuovo processo è iniziato molto rapidamente in modo da non effettivamente notato, ma tutte le sessioni sono perso.

Ecco un articolo che spiega molto meglio di me: ASP.NET 2.0 Eccezione non Gestita Problemi

citazione:

Un'eccezione non gestita in un esecuzione ASP.NET 2.0 applicazione che di solito terminare l'W3WP.exe processo, e vi lascio con una criptica EventLog voce qualcosa di simile a questo:

"EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.1830, P3 42435be1 P4 app_web_ncsnb2-n, P5 0.0.0.0, P6 440a4082, P7 5, P8 1, P9 sistema.nullreferenceexception, P10 NULLA."

Ecco un articolo della KB di Microsoft che spiega lo stesso problema: KB911816 le eccezioni non gestite causare ASP.NET-based applicazioni improvvisamente in .NET Framework 2.0

Answer 5

La mia ipotesi è il consumo di memoria, ma il set up IIS per accedere ricicla e sai per certo.