Ir para o conteúdo

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.

  1. Localize as entradas do sistema:

    Imagem 2016 10 26 9 44 6

  2. Encontre um evento com Fonte de WAS e entrada similar a:

    Imagem 2016 10 26 9 56 56

  3. 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:

    Imagem 2016 10 26 9 46 46

  4. 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:

    Imagem 2016 10 26 9 58 33

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.

  1. Pare o IIS. Em uma linha de comando administrativo, digite: iisreset /stop

    Imagem 2016 10 26 10 7 28

  2. Aguarde um minuto antes de iniciá-lo novamente. Então digite: iisreset /start

    Imagem 2016 10 26 10 10 20

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)

Imagem 2016 10 26 9 58 33

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.:

Imagem 2016 10 26 10 13 45

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