Teste o comportamento sempre em execução no Jitterbit App Builder
Visão geral
Esta configuração pode ser um pouco complicada de testar. O App Builder 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 aguarda o primeiro usuário fazer login no App Builder e, em seguida, inicia o pool de aplicativos.
Isso significa que o comportamento padrão do IIS interromperá o aplicativo App Builder e o agendador deixará de ser executado até que o próximo usuário efetue login no IIS.
Como um exemplo extremo, suponha que há um evento agendado para ser executado no domingo às 2h da manhã. O IIS recicla o aplicativo App Builder no sábado à meia-noite, e ninguém faz login no App Builder até segunda-feira de manhã. Neste exemplo, o agendador ficaria offline até segunda-feira de manhã, quando o primeiro usuário faz login, iniciando o aplicativo e derrotando o propósito de ter um evento agendado para domingo às 2h 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 o App Builder durante o teste. Se um usuário fizer login no App Builder enquanto testa esse recurso, ele invalida o teste porque o IIS carrega o pool de aplicativos quando o usuário acessa o 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 pool de aplicativos do App Builder sendo reciclado. Se for, então esse evento representa o IIS reciclando o pool de aplicativos do App Builder:
-
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 aplicativo App Builder deve iniciar sozinho. Para determinar isso, localize seus logs do App Builder e encontre entradas de log que correspondam à data e à hora deste evento de reciclagem. Os logs estão na pasta de instalação do App Builder em App_Data:
Observe que às 9:52:42 AM o Application Pool foi reciclado. Em seguida, observe no log do App Builder que às 9:52:45 (dentro de 3 segundos), o App Builder Application 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 no App Builder, ele foi iniciado imediatamente após o application pool ser reciclado. Novamente, este teste pressupõe que ninguém esteja usando o App Builder no momento. Se você quiser confirmar que nenhum usuário acessou o 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 o 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
Após iniciado, verifique os logs do aplicativo App Builder no diretório de instalação do App Builder em App_Data. Deve haver uma entrada de log indicando que o aplicativo foi iniciado imediatamente após você iniciar o IIS.
Nota
Isso pode levar mais tempo se você usar a Tarefa Agendada do Windows para executar ping no App Builder)
Verifique a data e a hora para confirmar que estão corretas (imediatamente após o horário em que você iniciou o IIS). Novamente, esse teste não é válido se um usuário estiver acessando o 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 Application Pool reinicie em horários diferentes todos os dias). Você deve configurar um horário específico do dia em que o Application Pool 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 os logs de aplicativos do App Builder para confirmar que o aplicativo App Builder foi iniciado imediatamente após o pool de aplicativos ter sido reciclado.
Se o aplicativo for iniciado automaticamente após a reciclagem do pool de aplicativos, o agendador 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 do comportamento de inicialização automática