Histórico da Página

CONTEÚDO

1. Visão Geral
2. Atualização da gjobserver
3. Tratamento para finalização do job quando o host que está executando-o não responde mais.

01. VISÃO GERAL

Neste documento serão citadas as melhorias que estão sendo feitas no funcionamento do Job, com o intuito de melhorar a sua performance.  

Veja mais sobre a Configuração N Camadas, Configuração do Jobserver na Linha RM.

02. ATUALIZAÇÃO DA GJOBSERVER

Na verão 12.1.31, foi feito um ajuste no tempo de escrita nessa tabela.

Essa tabela possui informações dos servidores de job em atividade. Alguns de seus dados são obtidos pelo arquivo de alias.dat e outros o sistema atualiza de forma dinâmica, de acordo com o ambiente.

Pode-se consultar:

• Qual é o servidor controlador, que distribui os processos da fila (gjobserver.controlador)
• Quantos Jobs são executados simultaneamente pelo Host (gjobserver.maxjobs ou alias.dat:<JobServerMaxThreads>) 

• Qual o intervalo de leitura da fila de processos (gjobserver.tempopool ou alias.dat: <JobServerPollingInterval>)

• Quantos Jobs estão sendo executados (gjobserver.numjobs)

Buscando melhorar a performance, o campo gjobserver.numjobs não mostrará mais quantos jobs estão sendo executados. Mas será preenchido com a regra:

0 - quando a quantidade de jobs em execução por aquele servidor forem igual a zero ou menor que a quantidade máxima que aquele server puder executar (maxjobs).

1 - quando o servidor estiver executando a quantidade máxima de jobs configurada para ele (maxjobs).

A escrita no campo gjobserver.dataultativ também foi alterada.

Antes este campo era atualizado sempre que era feita uma verificação da fila de jobs pelo sistema. Essa verificação é feita de acordo com o valor configurado em gjobserver.tempopool.

Após a implementação da melhoria, o campo gjobserver.dataultativ será atualizado após 5 vezes o tempo configurado em gjobserver.tempopool.

03. TRATAMENTO PARA FINALIZAÇÃO DO JOB QUANDO O HOST QUE ESTÁ EXECUTANDO-O NÃO RESPONDE MAIS 

Na verão 12.1.31, foi feita uma melhoria de reovery do job. 

Hoje um job em execução têm afinidade com o servidor que ele está em execução. A melhoria implementada afeta um cenário onde garantimos que se esse servidor cair durante a execução de um job e não retornar mais, outro servidor assumirá o processo.

Caso o job não tenha recorrência, o novo servidor irá assumir o processo (glbxexecucao.servidor) e atualizá-lo com status de falha. 

Se o job for recorrente, o novo servidor além de finalizar o processo com status de falha, irá criar o agendamento da próxima execução, considerando as mesmas regras da recorrência programada no job.

O processo acima ocorrerá quando o próprio host da execução inicial do job não conseguir finalizá-lo antes de cair e a hora de início da execução do job tiver passado mais que 1 hora.

Exemplo do fluxo:

O job 103746 começou sua execução às 12:00 pelo host Teste1:8050.

As 12:10 o host Teste1:8050 cai e não responde mais

O host Teste1:8052 assume o papel do host controlador e as 13:00 finaliza o job 103746 com status de falha