Thread BackgroundWorker no ASP.NET

É possível usar o segmento BackGroundWorker no ASP.NET 2.0 para o cenário a seguir, para que o usuário no final do navegador não precise esperar por muito tempo?

Cenário

  1. O navegador solicita uma página, digamos SendEmails.aspx
  2. A página SendEmails.aspx cria um thread BackgroundWorker e fornece o segmento com contexto suficiente para criar e enviar emails.
  3. O navegador recebe a resposta do ComposeAndSendEmails.aspx, dizendo que e-mails estão sendo enviados.
  4. Enquanto isso, o segmento de segundo plano está envolvido em um processo de criação e envio de e-mails, o que pode levar um tempo considerável para ser concluído.

Minha principal preocupação é manter o segmento BackgroundWorker em execução, tentando enviar 50 e-mails, enquanto o thread do threadpool do processo workerProcess do ASP.NET já não existe mais.

Se você não quiser usar as bibliotecas AJAX, ou se o processamento de email for REALMENTE longo e expirar uma solicitação AJAX padrão, você poderá usar um método AsynchronousPostBack que foi o “antigo hack” no .net 1.1 dias.

Essencialmente, o que você faz é fazer com que seu botão de envio inicie o processamento de e-mail em um estado asynchronous, enquanto o usuário é levado para uma página intermediária. O benefício disso é que você pode ter sua atualização de página intermediária o quanto for necessário, sem se preocupar em atingir os tempos limite padrão.

Quando o processo de segundo plano estiver concluído, ele colocará um sinalizador “concluído” na variável database / aplicativo / o que quer que seja. Quando sua página intermediária faz uma atualização de si própria, ela detecta esse sinalizador e redireciona automaticamente o usuário para a página “concluído”.

Novamente, o AJAX torna tudo isso irrelevante, mas se por algum motivo você tiver um processo muito intenso ou oportuno que precisa ser feito pela Web, essa solução funcionará para você. Eu encontrei um bom tutorial sobre isso aqui e há muito mais por aí.

Eu tive que usar um processo como este quando estávamos trabalhando em um aplicativo de tipo “web check-in” que fazia interface com um aplicativo de terceiros e sua API de importação era terrivelmente lenta.

EDIT: GAH! Maldito Guzlar e suas habilidades de digitação divinas 8 ^ D.

Você não deve fazer nenhum encadeamento de páginas ASP.NET. Qualquer thread que esteja em execução há muito tempo corre o risco de ser morto quando o processo do operador é reciclado. Você não pode prever quando isso vai acontecer. Qualquer processo de longa duração precisa ser tratado por um serviço do Windows. Você pode iniciar esses processos descartando uma mensagem no MSMQ, por exemplo.

ThreadPool.QueueUserWorkItem(delegateThatSendsEmails) 

ou no System.Net.Mail.SmtpServer use o método SendAsync.

Você quer colocar o código de envio de email em outro thread, porque ele retornará o usuário imediatamente, e apenas processará, não importa quanto tempo demore.

É possível. Depois de iniciar um novo thread de forma assíncrona a partir da página, a solicitação de página continuará e enviará a página de volta ao usuário. O encadeamento asynchronous continuará sendo executado no servidor, mas não terá mais access à session.

Se você tiver que mostrar o progresso da tarefa, considere algumas técnicas do Ajax.

O que você precisa usar para este cenário é Páginas assíncronas, um recurso que foi adicionado no ASP.NET 2.0

As páginas assíncronas oferecem uma solução simples para os problemas causados ​​por solicitações vinculadas a E / S. Processamento de página começa em um thread de pool de segmentos, mas esse thread é retornado para o pool de segmentos uma vez que uma operação de E / s assíncrona começa em resposta a um sinal do ASP.NET. Quando a operação é concluída, o ASP.NET pega outro thread do pool de threads e finaliza o processamento da solicitação. A escalabilidade aumenta porque os encadeamentos de pool de encadeamentos são usados ​​com mais eficiência. Segmentos que de outra forma ficariam presos esperando pela conclusão da E / S agora podem ser usados ​​para atender outras solicitações. Os beneficiários diretos são solicitações que não realizam longas operações de E / S e, portanto, podem entrar e sair do canal rapidamente. Longas esperas para entrar no pipeline têm um impacto desproporcionalmente negativo no desempenho de tais solicitações.

http://msdn.microsoft.com/pt-br/magazine/cc163725.aspx

Se você quiser usar multitheading em sua página ASP, você pode usar o modelo de threading simples como este:

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

Este método está correto trabalhando com páginas ASP. A página ASP com BackgroundWorker não será iniciada enquanto o BackgroundWorker será concluído.

5 anos depois, mas com problemas iguais… Se você deseja realizar operações de ignorar e esquecer do seu aplicativo e esquecer todas as dificuldades relacionadas ao processamento de tarefas em segundo plano em aplicativos ASP.NET, você pode usar o http://hangfire.io .

  • Ele não perde seus trabalhos no processo de recyclerview, porque usa armazenamento persistente para manter informações sobre trabalhos em segundo plano.
  • Ele repete automaticamente as tarefas em segundo plano que foram interrompidas ou falharam devido a uma exceção temporária (erros de conectividade do servidor SMTP).
  • Ele permite que você depure facilmente tarefas em segundo plano por meio da interface da Web integrada.
  • É muito fácil instalar / configurar / usar o HangFire.

Há também o tutorial Enviando mensagens em segundo plano com o ASP.NET MVC para usar o HangFire com Postal .