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

Tinhamos o seguinte cenário:

“É tentado cobrar um determinado valor do cartão de crédito do cliente, caso a operadora retorne OK, ou seja, a compra foi executada com sucesso, deve ser chamada uma API aqui da empresa que autoriza o cliente a usar o nosso sistema”

Agora pense na seguinte situação: O cliente é cobrado, debita o valor do seu cartão de crédito, mas quando
a API de autorização é chamada, acontece um erro e o cliente não é liberado para usar o sistema. O que fazer neste caso? Rollback da transação??? ahmmmm…não existe rollback na operadora de cartão de crédito! Mas mesmo se tivesse, ao meu ver essa não seria a solução ideal, afinal de contas, você perderia uma “venda”.

É aí que entra JMS e o título do post: “Contendo falhas de forma elegante”.

Nós adotamos a seguinte solução para este caso: Quando a operadora cobra o cliente, não há mais como voltar atrás, então, até esse ponto é fluxo é sincrono e, a autorização se tornou um fluxo assincrono. Com isso, foi criada uma  fila JMS e o cliente é colocado nesta fila para ser autorizado. A grande vantagem disso é que, em caso de um problema, a API do JMS possui uma propriedade configurável que faz com que ele retente processar de tempos em tempos. Com isso, caso o sistema não consiga autorizar o cliente na primeira vez, ele vai tentar novamente após 30 minutos, até 10 tentativas. Tempo suficiente para, se for um problema de banco por exemplo, o problema ser corrigido.

Mas não acaba aí, no JMS existe um conceito chamado “fila morta”. Caso após as 10 tentativas, o sistema não consiga processar aquela tarefa, ela será enviada para está fila. No nosso sistema, foi criada uma monitoração nesta fila. Caso algum registro caia na famigerada “fila morta”, o sistema irá alarmar e uma equipe responsável entrará em ação para solucionar o problema e após isso, reprocessar o registro.

Com isso, é possível uma ação totalmente pró-ativa, evitando assim chamadas na “Central de Atendimento” de clientes que pagaram e não receberam autorização para acessar o sistema.

Na nossa experiência aqui na empresa, JMS tem se mostrado uma excelente solução, tanto pela sua facilidade de uso com o auxílio de um servidor de aplicação, como o Jboss por exemplo, como também pela elegância e robustez que ele prove no seu uso.

Recomendo a todos os programadores Java a se aprofundarem neste assunto!

Um abraço!

Por um lado, essa característica é boa, pois força o seu cliente a sempre estar com a mesma versão da que está rodando no servidor. Mas, por outro lado, as vezes você quer adicionar uma constante ao seu enum, que em nada interfirá na maioria dos sistemas que estão usando o seu. Por exemplo:

-Um determinado sistema trata retornos com status PAGO e NÂO_PAGO.

Você quer adicionar um novo status de ANALISE na sua enum. Em tese, esse status não interessa para o sistema descrito acima, então, caso ele receba esse status ele poderia simplesmente ignora-lo. Mas com enum isso não é possível. Ou seja, se você tem 50 sistemas usuários do seu, e quer adicionar um novo status que só interessa para um deles, você é obrigado a forçar os 50 sistemas a atualizarem a versão “client” que receberam do seu.

O primeiro ponto é que o site da Jboss tem uma documentação muito boa ensinando fazer essa configuração.
Segue o link: http://wiki.jboss.org/wiki/ConfigDataSources

Porém, uma dúvida que o pessoal costuma ter é quando usar <local-tx-datasource> e quando usar <xa-datasource>.

Bom, a principal diferença entre os dois é que o <xa-datasource> suporta transações distribuidas, ou seja, vamos supor que você tem um método que realiza mudanças em duas tabelas. Até ai tudo bem. Porém, estas tabelas estão
em banco de dados diferentes. É nessa situação que você precisa de um <xa-datasource>. Se der algum problema e você
precisar fazer rollback, você precisa fazer rollback nas duas bases de dados. Um XADataSource fornece essa
caracteristica ao seu sistema. Ele gerencia a sua transação que passa por vários bancos de dados.

Se sua aplicação lida apenas com um banco de dados em uma máquina, o que você precisa é simplesmente de um <local-tx-datasource>.

Então é isso.

[]‘s

Após diversos testes, descobrimos que para que as conexões do pool sejam recuperadas é preciso adicionar o seguinte parâmetro nas configurações do datasource:

[sourcecode language='xml']<valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker</valid-connection-checker-class-name>[/sourcecode]
Esse parâmetro faz com que antes do pool devolver uma conexão, ele a valida, e se ela estiver inválida, ele descarta essa conexão e cria uma nova. Ao meu ver, isso deveria ser algo feito por “default”, mas infelizmente não é.

Esse problema só ocorre se você usa datasources XA. Com datasources “normais” nem é preciso adicionar este parâmetro.

Nós aqui da equipe também executamos outros testes como trocar a senha do banco de dados por exemplo, e neste caso, mesmo sem o parâmetro o sistema consegue se recuperar.

Então, pra finalizar, segue a configuração completa de um datasource XA:

[sourcecode language='xml']<xa-datasource>
<jndi-name>NameDS</jndi-name>
<track-connection-by-tx/>
<isSameRM-override-value>false</isSameRM-override-value>
<xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
<xa-datasource-property name="URL">jdbc:oracle:thin:@host:1521:SID</xa-datasource-property>
<xa-datasource-property name="User">user</xa-datasource-property>
<xa-datasource-property name="Password">password</xa-datasource-property> <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
<no-tx-separate-pools/>
<max-pool-size>3</max-pool-size>
<valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker</valid-connection-checker-class-name>

[/sourcecode]

Espero que essas dicas sejam utéis e possam ajudar a outros também que tiverem esse mesmo problema.