Cosa succede se si attiva un thread in background per eseguirlo prima che ASP.NET completi l'elaborazione della pagina?

Question

cosa accadrebbe se eseguissi un thread per eseguire un processo di lunga durata prima del completamento del ciclo di vita della pagina ASP.NET? Il runtime di ASP.NET terminerà il thread? Questo può portare a comportamenti non definiti?

Ecco un esempio del codice, che fa girare il thread in background nell'evento Page_Load. È una cosa sicura da fare?

protected void Page_Load(object sender, EventArgs e) 
{ 
    Thread newThread = new Thread(new ThreadStart(SomeLongRunningMethod)); 
    newThread.IsBackground = true; 
    newThread.Start(); 
} 

private void SomeLongRunningMethod() 
{ 
    // some long running process goes here... 
} 

Answer 1

Ho fatto qualche esperimento con lo stesso tipo di codice eseguendo un po 'di tempo con la registrazione in un thread separato. Sembra funzionare bene, ma non l'ho testato in un ambiente di produzione.

L'unica differenza tra il tuo codice e il mio è che ho usato il pool di thread invece di impostare un nuovo thread.

Probabilmente farai copie di qualsiasi richiesta dati e altre informazioni sulla pagina per evitare che vengano smaltite, ma a parte questo penso che questo dovrebbe funzionare bene.

Answer 2

essere a conoscenza delle impostazioni di riciclo di lavoro IIS in quanto questi potrebbero comunque influenzare la discussione dopo che è stato avviato. Assicurati di rilevare eventuali eccezioni e registrarle.

Answer 3

Ho eseguito la conversione/elaborazione video con ffmpeg su film caricati dagli utenti su un modulo Web e ha funzionato perfettamente, anche se il thread ha impiegato parecchie ore per essere completato! È molto importante tenere a mente che è difficile scoprire lo stato del thread, quindi la registrazione e la gestione degli errori è estremamente importante.

Answer 4

Un collega di recente ha fatto questo per alcune esportazioni di dati. Il client si collegava a un pannello di controllo (basato sul Web) e quindi premeva alcuni pulsanti e cosa no e quindi un file sarebbe stato trasferito via FTP su un server mistico.

Il front-end è stato eseguito utilizzando ASP AJAX e come dice @bang, il thread viene eseguito correttamente ma è una merda assoluta da tenere traccia di.

AJAX è stato utilizzato per aggiornare una barra di stato e una riga di stato nell'interfaccia utente, il che era bello in teoria e mentre il set di dati era solo un paio di centinaia di righe. Ma non appena abbiamo iniziato a lavorare con il set di dati reale (milioni di righe) l'intera interfaccia utente ha continuato a bombardare con errori di timeout. A questo punto si perde contatto con il thread in background ...

è ancora in esecuzione? L'esportazione è finita? Cosa succede se aggiorno la pagina e premo di nuovo il pulsante? La casa dell'adempimento manderà due prodotti alla gente?

È un po 'un incubo. Al momento sta riscrivendola per essere eseguita come app di console pianificata con l'utilità di pianificazione di Windows collegata a una tabella di lavori che contiene i dettagli delle esportazioni che devono essere eseguite.

Se questo sembra un po 'shonkey, puoi sempre scrivere il tuo processo di lunga durata con un po' di socket server e comunicare con il tuo codx di aspx.