Domanda

È possibile utilizzare il BackGroundWorker thread ASP.NET 2.0 per il seguente scenario, in modo che l'utente del browser fine non è necessario aspettare per lungo tempo?

Scenario

  1. Il browser richiede una pagina, dire SendEmails.aspx
  2. SendEmails.pagina aspx crea un BackgroundWorker thread, e fornisce il filo con il contesto sufficienti per creare e inviare messaggi di posta elettronica.
  3. Il browser riceve la risposta dal ComposeAndSendEmails.aspx, dicendo che le e-mail vengono inviati.
  4. Nel frattempo, il thread in background è impegnata in un processo di creazione e invio di messaggi di posta elettronica, che potrebbe richiedere un certo tempo per completare.

La mia principale preoccupazione è mantenere il BackgroundWorker thread in esecuzione, tentando di inviare, diciamo 50 e-mail, mentre il ASP.NET workerprocess threadpool thread è andato lungo.

È stato utile?

Soluzione

Se non si desidera utilizzare le librerie AJAX, o l'e-mail di elaborazione è molto lungo e sarebbe timeout standard richiesta AJAX, è possibile utilizzare un AsynchronousPostBack metodo che è stato il "vecchio trucco" in .net 1.1 giorni.

Essenzialmente quello che devi fare è avere il pulsante di invio per iniziare l'elaborazione delle e-mail in modalità asincrona stato, mentre l'utente è preso una pagina intermedia.Il vantaggio di questo è che si può avere la vostra pagina intermedia di aggiornamento per quanto necessario, senza preoccuparsi di colpire gli standard di timeout.

Quando il processo in background, si metterà un po ' "fatto" flag nel database dell'applicazione/variabile/qualunque cosa.Quando il vostro intermedio pagina fa un refresh della stessa, rileva questo flag e reindirizza automaticamente l'utente al "fatto" della pagina.

Di nuovo, AJAX rende tutto opinabile, ma se per qualche motivo si sono molto intense e tempestivo processo che deve essere fatto sul web, questa soluzione funziona per voi.Ho trovato un bel tutorial su di esso qui e ci sono un sacco di più là fuori.

Ho dovuto utilizzare un processo come questo, quando stavamo lavorando su un "web check-in" tipo di applicazione che è stata l'interfacciamento con un'applicazione di terze parti e la loro importazione di API era mostruosamente lento.

EDIT:GAH!Maledizione si Guzlar e, il vostro dio, come scrivere le capacità 8^D.

Altri suggerimenti

Si dovrebbe fare qualsiasi filettatura da ASP.NET pagine.Qualsiasi thread che è lunga la corsa è in pericolo di essere ucciso durante il processo di lavoro, ricicla.Non si può prevedere quando questo accadrà.Qualsiasi lungo in esecuzione, i processi devono essere gestiti da un servizio di windows.Si può dare il via a questi processi di eliminazione di un messaggio di MSMQ, per esempio.

ThreadPool.QueueUserWorkItem(delegateThatSendsEmails)

o sul Sistema.Net.Mail.SmtpServer utilizzare il metodo SendAsync.

Vuoi mettere l'e-mail l'invio di codice in un altro thread, perché poi verrà restituito l'utente immediatamente, e sarà solo processo, non importa quanto tempo ci vuole.

È possibile.Una volta che si inizia un nuovo thread, in modo asincrono, dalla pagina, pagina di richiesta di procedere e invia la pagina dell'utente.Async thread continuerà a funzionare sul server ma non avrà più accesso alla sessione.

Se è necessario visualizzare l'avanzamento delle attività, in considerazione alcune tecniche Ajax.

Ciò che è necessario utilizzare per questo scenario è Asincroni Pagine, una caratteristica che è stata aggiunta in ASP.NET 2.0

Asincroni pagine sono pulite soluzione ai problemi causati da I/O-bound richieste.L'elaborazione della pagina inizia un thread del pool di thread, ma che il thread è tornato al thread piscina una volta un I/O asincrono l'operazione inizia in risposta a un segnale ASP.NET.Quando il completata l'operazione, ASP.NET afferra un altro thread dal pool e termina l'elaborazione della richiesta.Scalabilità aumenta perché thread del pool di thread più in modo efficiente.Thread che sarebbe altrimenti bloccati in attesa di I/O per completa può ora essere utilizzato per il servizio di altre richieste.La diretta i beneficiari sono le richieste che non eseguire lunghe operazioni di I/O e può quindi ottenere in e fuori del pipeline rapidamente.Lunghe attese per ottenere in pipeline hanno un sproporzionatamente impatto negativo sul le prestazioni di tali richieste.

http://msdn.microsoft.com/en-us/magazine/cc163725.aspx

Se si desidera utilizzare multitheading nella pagina ASP, si potrebbe utilizzando un semplice modello di threading come questo:

{
    System.Threading.Thread _thread = new Thread(new ThreadStart(Activity_DoWork));
    _thred.Start();
}
Activity_DoWork()
{
    /*Do some things...
}

Questo metodo è corretto lavorare con le pagine ASP.La pagina ASP con BackgroundWorker non si avvia mentre BackgroundWorker a finire.

5 anni più tardi, ma il problema è lo stesso... Se si desidera eseguire fire-and-forget le operazioni di applicazione e dimenticare tutte le difficoltà relative al processo in background di elaborazione in ASP.NET applicazioni, è possibile utilizzare http://hangfire.io.

  • Non perdere i posti di lavoro nel processo di riciclaggio, perché utilizza la memorizzazione persistente di mantenere le informazioni sui processi in background.
  • Automaticamente i tuoi tentativi di processi in background che sono stati abortiti o non è riuscito a causa della transitorie eccezione (Server SMTP errori di connettività).
  • Permette di eseguire il debug dei processi in background tramite l'interfaccia web integrata.
  • È molto facile da installare/configurare/usare HangFire.

C'è anche il tutorial L'invio di Mail in Background con ASP.NET MVC per l'utilizzo di HangFire con Postale.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top