O uso de timers no jboss não é nenhum mistério, você consegue achar vários links na internet explicando como criar um EJB Timer. Entretanto, quando temos um cluster de servidores encontramos um problema: Qual instância deverá executar o serviço de timer. Este tipo de serviço é do tipo Highlander (somente um pode existir), pois caso contrário podemos ter problemas de concorrência.
O Jboss oferece duas maneiras de se disponibilizar um serviço único dentro de um cluster (e isso é bem anterior a proposição de @Singleton do EJB 3.1). A primeira, seria colocarmos nosso arquivo no diretorio HA-Singleton, mas nem sempre funciona, uma vez que algumas dependências podem ainda não terem sido resolvidas no momento da inicialização da sua aplicação. A outra maneira, é criar uma dependência com o BarrierController.
Existe um link no wiki do jboss que demonstra como criar o serviço de timer em cluster. O que vou mostrar aqui é uma alternativa usando MDBs que na minha opinião é muito mais simples que a usando Timers, você pode comparar ambas e ver a diferença.
Criando um MDB sem JMS
Message Driven Beans são amplamente utilizados em aplicações que usam batch processing de forma que possam ser executados de forma assíncrona. A sua forma mais tradicional é ouvindo uma fila JMS, mas o que muitos não sabem, é que um MDB pode ouvir outros eventos, desde que exista um Resource Adapter configurado para ele. Você pode criar um RA para um CICS, ERP ou outro sistema legado que possa notificar um MDB por exemplo.
O Jboss oferecer um RA chamado quartz-ra.rar que permite que eventos gerados pelo quartz possam notificar um MDB. Com esta abordagem teremos o nosso timer, so que ao invés de escutarmos uma fila JMS vamos escutar um Job quartz.
O código de nosso MDB se encontra na listagem abaixo:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| package com.furiousbob.timer;
import org.quartz.Job;
import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;
public class ConsoleTimer implements Job {
public void execute(JobExecutionContext ctx) throws JobExecutionException {
System.out.println("WAKE UP!!!!!!");
}
} |
A primeira coisa que vocês devem ter notado é que esta classe não implementa javax.jms.MessageListener, pode soar estranho, mas como havia dito um MDB não precisa depender de uma fila JMS e como não vamos ouvir uma fila, então por que devemos implementar uma interface de JMS?
Por isso implementamos então a interface de execução de jobs do quartz.
Neste primeiro exemplo não vamos usar anotações. Isso pois acredito que a frequência de execução deveria ficar em um arquivo xml e não dentro do MDB, uma segunda listagem será apresentada mostrando a alternativa com anotações
Em termos de código é só isso 
, precisamos agora configurar nosso ejb-jar.xml para informar que usamos um MDB:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| <?xml version="1.0" encoding="UTF-8" ?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="3.0"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
<enterprise-beans>
<message-driven>
<ejb-name>ConsoleTimer</ejb-name>
<ejb-class>com.furiousbob.timer.ConsoleTimer</ejb-class>
<messaging-type>org.quartz.Job</messaging-type>
<transaction-type>Container</transaction-type>
<activation-config>
<activation-config-property>
<activation-config-property-name>cronTrigger</activation-config-property-name>
<activation-config-property-value><![CDATA[30 * * * * ?]]></activation-config-property-value>
</activation-config-property>
</activation-config>
</message-driven>
</enterprise-beans>
</ejb-jar> |
O que temos de diferente neste arquivo são as linhas 10 e 12-17. Na linha 10 informamos ao container que o tipo de interface que vamos usar, em anotações teríamos algo como @MessageDriven(messageListenerInterface=Job.class). As linhas 12-17 são configurações do bean, onde normalmente informaríamos o nome da queue/topic a ser consumida, aqui informamos a expressão do cronTrigger (para maiores informações consulte este link)
Agora precismos informar ao JBoss qual resource adapter vamos usar para este bean, para isso modifique o arquivo jboss.xml:
1
2
3
4
5
6
7
8
9
| <?xml version="1.0" encoding="UTF-8"?>
<jboss>
<enterprise-beans>
<message-driven>
<ejb-name>ConsoleTimer</ejb-name>
<resource-adapter-name>quartz-ra.rar</resource-adapter-name>
</message-driven>
</enterprise-beans>
</jboss> |
Pronto, agora basta fazer deploy de seu novo MDB que é na verdade um timer. Você irá notar o console tendo saídas a cada minuto sempre aos 30s de cada minuto.
Cluster Safe Timers
Ok, agora você tem seu timer, ele acorda a cada X segundos, mas você precisa de um cluster de alta disponibilidade, ou seja você precisa que o serviço esteja sempre disponível, mesmo quando uma máquina falhe. A primeira idéia seria colocar este serviço replicado em cada nó do cluster, como fazemos com um SLSB ou SFSB. O problema dessa abordagem é que no caso de SLSB como não possuem estado tanto faz onde o cliente “aterrisa”, no caso de SFSB o JBoss (e sinceramente, o mecanismo de cluster mais fantástico de todos App Servers que conheço), replica o estado entre os nós usando JBossCache/JGroups para você. Agora e no caso de um serviço que pode existir apenas uma instância em execução? Neste caso, adicionamos ao nosso serviço uma dependência com o servico BarrierController como o arquivo jboss.xml modificado abaixo:
1
2
3
4
5
6
7
8
9
10
| <?xml version="1.0" encoding="UTF-8"?>
<jboss>
<enterprise-beans>
<message-driven>
<ejb-name>ConsoleTimer</ejb-name>
<resource-adapter-name>quartz-ra.rar</resource-adapter-name>
<depends>jboss.ha:service=HASingletonDeployer,type=Barrier</depends>
</message-driven>
</enterprise-beans>
</jboss> |
Note que agora temos uma mudança na linha 7 indicando a dependência com o serviço. Pronto, seu serviço esta pronto para rodar em clusters de forma consistente. Sempre que um nó cair, outro toma seu lugar e faz o deploy do serviço.
Esta solução é mais simples que a apresentada pelo wiki do jboss, e já usei em produção em sistemas e garanto que funciona 
Tirando onda com seus amigos
O que vou mostrar aqui é um pequeno passo a passo de como subir duas instâncias do jboss em cluster, na mesma máquina, com replicação de estado e com o serviço de timer, isto aqui é só para você mostrar aos seus amigos como é simples criar clusters com jboss
Vamos usar o jboss 4.2.3.GA rodando em um Ubuntu 8.10. O primeiro passo é você fazer uma cópia da pasta all pois teremos 2 configurações distintas, eu normalmente copio a pasta all para node1 e node2:
vinicius@cybertron:~/java/jboss-4.2.3.GA/server$ cp -R all/ node1
vinicius@cybertron:~/java/jboss-4.2.3.GA/server$ cp -R all/ node2
Bem, vamos subir 2 instâncias de jboss na mesma máquina, aqui você tem 2 alternativas:
Subir cada instância em IPs distintos, mas mantendo as portas
Alterar as portas de uma instância e subir ambas na mesma interface
Vamos adotar a segunda abordagem. E vamos fazer o seguinte, node1 irá subir nas portas padrão (8080,1099,8009) e node2 vai subir em portas alternativas (8180,1199,8109). Se você não sabe como fazer, vai aqui mais uma dica
Alterando as portas do JBossAS
Como vamos alterar as portas do node2, entre em node2/conf e edite o arquivo jboss-service.xml. Procure pelo trecho mostrado abaixo:
1
2
3
4
5
6
7
8
| <mbean code="org.jboss.services.binding.ServiceBindingManager"
name="jboss.system:service=ServiceBindingManager">
<attribute name="ServerName">ports-01</attribute>
<attribute name="StoreURL">${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml</attribute>
<attribute name="StoreFactoryClassName">
org.jboss.services.binding.XMLServicesStoreFactory
</attribute>
</mbean> |
O trecho apresentado estará comentado, basta remover o comentário do mesmo. O que isto faz é ler um arquivo de bindings (dê uma lida no arquivo para entender sua estrutura) e então atribuir as portas de serviço do jboss de forma dinâmica. Note que no arquivo existem várias pre-configurações (ports-default, ports-01,ports-02….) de forma a simplificar sua vida
Bem, agora quando você subir a instância node2 ela não terá conflito de portas com node1.
Cluster e Multicast
Toda comunicação entre os nós do cluster no jboss é feita por multicasting, portanto você precisa habilitar uma rota de multicast em seu linux (no windows isso não é necessário). Eu recomendo que vocês dêem uma lida neste artigo, mas para simplificar as coisas vou passar o comando que devem executar em seu linux
route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
O -net é necessário apenas em algumas distro (no ubuntu é necessário)
Pronto, agora você esta pronto para executar suas instâncias de jboss. Abra duas janelas de terminal e execute os comando abaixo no diretório bin/
vinicius@cybertron:~/java/jboss-4.2.3.GA/bin$ ./run.sh -c node1
vinicius@cybertron:~/java/jboss-4.2.3.GA/bin$ ./run.sh -c node2
Para verificar se suas instâncias estão se comunicando procure pela mensagem abaixo em um dos consoles
-------------------------------------------------------
GMS: address is 127.0.0.1:42880
-------------------------------------------------------
10:55:32,391 INFO [DefaultPartition] Number of cluster members: 2
10:55:32,391 INFO [DefaultPartition] Other members: 1
10:55:32,391 INFO [DefaultPartition] Fetching state (will wait for 30000 milliseconds):
10:55:32,504 INFO [DefaultPartition] state was retrieved successfully (in 112 milliseconds)
10:55:32,622 INFO [HANamingService] Started ha-jndi bootstrap jnpPort=1200, backlog=50, bindAddress=/127.0.0.1
10:55:32,627 INFO [DetachedHANamingService$AutomaticDiscovery] Listening on /127.0.0.1:1102, group=230.0.0.4, HA-JNDI address=127.0.0.1:1200
10:55:32,877 INFO [TreeCache] No transaction manager lookup class has been defined. Transactions cannot be used
10:55:33,235 INFO [STDOUT]
-------------------------------------------------------
GMS: address is 127.0.0.1:56144
-------------------------------------------------------
Note a existência de 2 clusters
Agora pegue seu arquivo modificado com a dependência do BarrierController e faça deploy em uma instância, depois realize o procedimento na outra instância. Note que em apenas um dos consoles o timer será executado. Agora, mate o processo no console que esta rodando o serviço, note que logo após ter matado o serviço o outro console irá assumir controle e registrará a seguinte mensagem:
10:59:27,627 INFO [EJBContainer] STARTED EJB: com.furiousbob.timer.ConsoleTimer ejbName: ConsoleTimer
A partir daí o novo nó será responsável pela execução do servico. Muito legal né? Espero que tenham curtido o post.
Grande Abraço
