Teste o Comportamento Sempre em Execução
Visão Geral
Esta configuração pode ser um pouco complicada de testar. O App Builder o Scheduler é executado dentro do processo do IIS. O problema é que para liberar memória o IIS recicla seus pools de aplicativos todos os dias por padrão. Depois que um pool de aplicativos é reciclado, por padrão, o IIS espera que o primeiro usuário faça login App Builder, então inicia o pool de aplicativos.
Isso significa que o comportamento padrão do IIS interromperá o App Builder aplicativo, e o agendador parará de executar até que o próximo usuário faça login no IIS.
Como um exemplo extremo, suponha que haja um evento agendado para ser executado no domingo às 2h. O IIS recicla o App Builder aplicação sábado à meia-noite, e ninguém faz login App Builder até segunda-feira de manhã. Neste exemplo, o agendador ficaria offline até segunda-feira de manhã quando o primeiro usuário fizer login, iniciando o aplicativo e derrotando o propósito de ter um evento agendado para domingo às 2 da manhã.
Para testar manualmente se o 'Always Running' está funcionando, há algumas opções, mas ambas as técnicas exigem que os usuários não usem App Builder durante o teste. Se um usuário fizer login em App Builder ao testar esse recurso, ele invalida o teste porque o IIS carrega o pool de aplicativos quando o usuário acessa App Builder.
Verifique os Logs de Eventos do Windows
Quando o IIS recicla o pool de aplicativos, uma entrada de log é adicionada ao log de eventos do Windows com uma fonte de WAS. Para encontrar a entrada de log, abra o Windows Event Viewer no servidor web.
-
Localize as entradas do sistema:
-
Encontre um evento com Fonte de WAS e entrada similar a:
-
Verifique os detalhes para ver se o evento é o App Builder o pool de aplicativos está sendo reciclado. Se sim, então este evento representa a reciclagem do IIS App Builder pool de aplicativos:
-
Verifique a data e a hora do evento. O objetivo da configuração Always Running é que, imediatamente após o pool de aplicativos ser reciclado, o App Builder o aplicativo deve iniciar sozinho. Para determinar isso, localize seu App Builder logs e encontrar entradas de log que correspondem à data e hora deste evento de reciclagem. Os logs estão no App Builder pasta de instalação em App_Data:
Observe que às 9:52:42 AM o Application Pool foi reciclado. Então observe no App Builder registre que às 9:52:45 (dentro de 3 segundos), o App Builder o aplicativo foi reiniciado. Isso indica que a configuração Always Running está funcionando para seu ambiente. O aplicativo não esperou até que alguém efetuasse login App Builder, ele começou imediatamente após o pool de aplicativos ser reciclado. Novamente, este teste pressupõe que ninguém esteja usando atualmente App Builder. Se você quiser confirmar que nenhum usuário acessou App Builder neste momento, forçando o aplicativo a iniciar, verifique os logs do IIS, pasta padrão:
C:\inetpub\logs\logfiles\w3scv1\
Confirme se não há solicitações que correspondam à hora e data em que o aplicativo foi iniciado.
Confirme Manualmente a Configuração
Novamente, isso precisa ser feito quando ninguém estiver usando App Builder ou o teste será inválido.
-
Pare o IIS. Em uma linha de comando administrativo, digite: iisreset /stop
-
Aguarde um minuto antes de iniciá-lo novamente. Então digite:
iisreset /start
Uma vez iniciado, verifique o App Builder registros de aplicativos no App Builder diretório de instalação em App_Data. Deve haver uma entrada de log indicando que o aplicativo iniciou imediatamente após você iniciar o IIS.
Nota
Isso pode levar mais tempo se usar a Tarefa Agendada do Windows para fazer ping App Builder)
Verifique a data e a hora para confirmar se estão corretas (imediatamente após o horário em que você iniciou o IIS). Novamente, este teste não é válido se um usuário estiver acessando App Builder suas solicitações também iniciarão imediatamente o pool de aplicativos.
Por padrão, o IIS é configurado para reiniciar a cada 29 horas (para que o pool de aplicativos reinicie em horários diferentes todos os dias). Você deve configurar um horário específico do dia em que o pool de aplicativos reinicia e certificar-se de que esse horário não interfira com os trabalhos em segundo plano agendados.:
Neste ponto, você pode escolher um horário em que sabe que os usuários não acessarão o sistema. Você pode então verificar os Logs de Eventos para confirmar que o pool de aplicativos foi reciclado no horário especificado (etapas incluídas na primeira opção) e pode verificar o App Builder logs de aplicação para confirmar que o App Builder aplicativo iniciado imediatamente após o pool de aplicativos reciclado.
Se o aplicativo estiver iniciando automaticamente após o pool de aplicativos ter sido reciclado, o planejador estará sempre em execução.
Solução de Problemas
Se o teste não for bem-sucedido, a seção a seguir contém alguns problemas comuns que foram encontrados ao implementar o comportamento de inicialização automática.
A inicialização do aplicativo agora está configurada corretamente. A seguir estão os links que indicam como testar o comportamento ou solucionar alguns problemas comuns que foram encontrados.
Solucionar problemas de comportamento de inicialização automática