Pretendo postar aqui as coisas bacanas que eu ver, e estarei em real-time twittando o que eu ver de legal por lá, então, se alguém tiver interesse e quiser me seguir, o meu twitter é luiz_hespanha.

No sistema que eu trabalho aqui na empresa, usamos muito JMS, então para nós, é imprecindível uma monitoração em cima dessa tecnologia.

Para quem não sabe, uma aplicação tenta enviar uma mensagem JMS um número configurado de vezes, caso a aplicação que recebe essa mensagem tenha problemas para receber a mensagem. Após o número X de vezes, a mensagem é enviada para uma DLQ, que traduzindo para o português é “fila-morta”. É este o ponto que estamos monitorando na nossa aplicação.

Criamos um método JMX que é chamado pelo Nagios de tempos em tempos, e que retorna OK se não existe nenhuma mensagem na DLQ, e NOK cc.

Caso retorne NOK, a minha equipe é avisada para que entre em ação e investigar o porquê da mensagem ter ido para a DLQ, e após isso, resgatar a mensagem da DLQ caso necessário.

O código para fazer isso é o seguinte:

public String validateMessagesSentToDLQ() {
   logger.info("+++++ Validando se ha ou nao mensagens na DLQ +++++");
   ObjectName name = null;
   List<SpyMessage> listMessages = null;
   String ret = RETURN_NOK;

   try {
      name = new ObjectName("jboss.mq.destination:service=Queue,name=DLQ");
      listMessages = (List<SpyMessage>) getRmiAdaptor().invoke(name, "listMessages", null, null);
      logger.info("Quantidade de mensages na DLQ: " + listMessages.size());
      if (listMessages.size() == 0) {
         ret = RETURN_OK;
      }
   } catch (Exception e) {
      logger.error("Problemas ao verificar se há mensagens na DLQ!", e);
   }
   return ret;
}

Este código funciona no JBoss 4.0.4. Não sei dizer se funciona em outros servidores ou versões do JBoss, mas se não funcionar, não deve ser difícil adaptar ele.

Bom, tá aí a dica! Recomendo essa monitoração. Já nos ajudou bastante aqui no UOL!

A configuração estava feita da seguinte forma:

<mbean code="org.jboss.varia.scheduler.Scheduler"
name="jboss.docs:service=MyScheduler">
<attribute name="TimerName">jboss:service=MyTimer</attribute>
<attribute name="SchedulableClass">br.com.uol.MyScheduler</attribute>
<attribute name="StartAtStartup">true</attribute>
<attribute name="DateFormat">dd/MM/yyyy HH:mm</attribute>
<attribute name="InitialStartDate">01/01/2006 03:00</attribute>
<attribute name="SchedulePeriod">86400000</attribute><!-- Roda uma vez por dia -->
<attribute name="InitialRepetitions">-1</attribute>
<depends>administration:custom=MyJMX</depends>
<depends>
<mbean code="javax.management.timer.Timer"
name="jboss:service=MyTimer"/>
</depends>

</mbean>

Foram levantadas hipóteses que o horário da máquina estava configurado errado, que o timezone estava errado, que
o horário de verão estava configurado errado etc. A gente investigou uma por uma e tudo estava OK.

Até que começou a fase do desespero, de começar a etapa de tentar resolver o problema por tentativa e erro, e dessa
forma, descobrimos o problema.

Por uma razão desconhecida, se o campo “InitialStartDate” é configurado para alguma data dentro do horário de verão,
ele só inicia no horário correto quando estamos no horário de verão. Para resolver esse problema, nós apelamos
e mudamos este campo para 01/09/2006, e finalmente o scheduler começou a rodar conforme esperado, as 3:00 da manhã.

Fica aí a dica para caso alguém também passe por este problema. A versão do JBoss usada é 4.0.4_GA.

É impressionante como horário de verão sempre traz problemas, mesmo a cada ano a gente cercando cada vez mais, sempre
tem algum efeito colateral!

[]‘s e até a próxima.

Primeiro vamos a um cenário onde este agendamento é útil.

Vamos supor que a seguinte regra é solicitada: Ao tentarmos cobrar o cartão do cliente, se a operadora retornar transação negada, o sistema deve re-tentar cobrar este cartão por mais 2 dias, sendo que cada tentativa deve ser feita após 24hs.

É possível resolver este requisito usando banco de dados e as famosas flags, mas essa definitivamente não é uma solução elegante. Imagina que você precisaria ficar fazendo pooling no banco para ver quais cobranças já passaram de 24 horas para processa-las novamente. Ou seja, horrível.

Com JMS dá pra fazer algo muito melhor. Se quando a compra é feita, retornar negado, basta enviar uma mensagem JMS pra fila, agendando essa mensagem para ser processada apenas após 24 horas. Quando der essas 24hhs, o MDB lê a mensagem e chama novamente o módulo de cobrança.

Muito simples e elegante. Sem pooling, sem ficar controlando status manualmente, nem nada desse tipo.

O código para fazer isso é extremamente simples:

[sourcecode language='java']
ObjectMessage message = session.createObjectMessage();

message.setLongProperty("JMS_JBOSS_SCHEDULED_DELIVERY", (new Date().getTime() + (1000 * 60 * 60 * 24)));[/sourcecode]

Pronto, você acabou de agendar a entrega da sua mensagem para daqui a 24 horas. Essa conta maluca aí é porque a data precisa ser passada em milisegundos.

Eu sou um grande fã de JMS, e essa é mais uma das caracteristicas que me fazem gostar dessa tecnologia.

[]'s