A fim de fazer testes com várias configurações diferentes e gerar um relatório com dados precisos, escrevi um script que executa o init script do JBoss, espera ele inicializar completamente, grava o tempo de inicialização e mata o processo. Faz isso 50 vezes.

Estou postando ele aqui na esperança de ser útil para mais alguém. Ele é bastante auto-explicativo:

#!/bin/bash
# Notes: all Java processes are going to the KILLED and
# previous probe.log ERASED!
 
JBOSS_LOG_FILE="/opt/jboss/server/default/log/server.log"
REPEAT=50
 
START_STRING="Started in"
RESULT_FILE="/root/probe.log-`date +%F`"
> $RESULT_FILE
 
for i in $(seq 1 $REPEAT); do
	# clean
	killall -9 java
	> $JBOSS_LOG_FILE
 
	# init and wait
	sh /etc/init.d/jboss start
	while [ "x$( grep "$START_STRING" $JBOSS_LOG_FILE )" == "x" ]; do
		sleep 1
	done
 
	# log
	cat $JBOSS_LOG_FILE | grep "$START_STRING" >> $RESULT_FILE
done
 
echo "Done"

1. Adicionando uma Category ao $JBOSS_CONF/conf/jboss-log4j.xml pegando todos o package da aplicação e usando um Appender específico. Por exemplo:

   <category name="net.rafaelliu">
     <priority value="INFO" />
     <appender-ref ref="BLOG_LOG"/>
   </category>

Embora seja a solução mais fácil, a separação não está perfeita. Como estamos separando por pacotes, um erro no Hibernate por exemplo, ainda vai ser escrito no server.log, mesmo tendo sido lançado pela aplicação.

2. Usando Filters é possível criar um TCLFilter para pegar apenas logs de determinada aplicação. Basta criar um Appender específico:

   <appender name="BLOG_LOG" class="org.jboss.logging.appender.DailyRollingFileAppender">
      <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
      <param name="File" value="${jboss.server.log.dir}/blog.log"/>
      <param name="Append" value="true"/>
      <param name="DatePattern" value="'.'yyyy-MM-dd"/>
      <layout class="org.apache.log4j.PatternLayout">
         <param name="ConversionPattern" value="%d %-5p [%c] (%t) %m%n"/>
      </layout>
 
      <!-- filter -->
      <filter class="org.jboss.logging.filter.TCLFilter">
         <param name="AcceptOnMatch" value="true"/>
         <param name="DeployURL" value="blog.war"/>
      </filter>    
      <filter class="org.apache.log4j.varia.DenyAllFilter"></filter>
   </appender>

O problema aqui é que, embora o log seja gravado separadamente (inclusive de pacotes do Hibernate, por exemplo), ele será gravado duas vezes: uma vez no blog.log que definimos e uma vez no server.log do JBoss. Isso resulta em mais IO e mais espaço em disco.

3. Empacotando um log4j na própria aplicação, em WEB-INF/lib, é possível inverter o classloader e fazer com que as configurações do log4j valham apenas para sua aplicação:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
	<class-loading java2ClassLoadingCompliance="false">
		<loader-repository>
			net.rafaelliu:loader=blog.war
			<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
		</loader-repository>
	</class-loading>
</jboss-web>

Feito isso, é preciso criar o log4j.properties (ou xml) normalmente:

log4j.rootLogger=${jboss.server.log.threshold}, fileout
 
log4j.appender.fileout=org.apache.log4j.DailyRollingFileAppender
log4j.appender.fileout.File=${jboss.server.log.dir}/blog.log
log4j.appender.fileout.Append=true
log4j.appender.fileout.DatePattern='.'yyyy-MM-dd
log4j.appender.fileout.layout=org.apache.log4j.PatternLayout
log4j.appender.fileout.layout.ConversionPattern=%d %-5p [%c] (%t) %m%n

O log4j faz parse de system properties, que podem ser usadas no arquivo de configuração. Uma observação importante é que não é possível usar classes do JBoss aqui! Isso causaria ClassCastExceptions. Algumas dicas:

• No JBoss 5, use o jboss.server.log.dir e o jboss.server.log.threshold. Isso facilitará o deploy da sua aplicação em outros ambientes;
• Use o mesmo Appender do jboss-log4j (provavelmente uma classe da JBoss estará lá, veja o equivalente da Apache). Isso deixa os logs do JBoss e das aplicações sincronizados, facilitando o correlacionamento de erros;

O problema dessa abordagem é que perdemos o “hot deploy” do jboss-log4j.xml, que nos permite alterar o nível de log sem indisponibilidade.

Referências:
http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PropertyConfigurator.html
http://viragine.blogspot.com/2009/02/separando-o-log-do-jboss-as-por.html
http://community.jboss.org/wiki/SeparatingApplicationLogs

Foi muito bom! Um dia inteiro com geeks das mais diversas áreas num ambiente de troca de conhecimento incrível. As fotos estão no Picasa.

O local do evento ficou apertado para o tanto de gente que deu. Em algumas apresentações as salas ficaram abarrotadas, como a do @brunorst e @claudio4j falando de Tuning de JBoss e a do @vtcorrea e @g_luszczynski falando de Alta Disponibilidade. Ambas as palestras muito bem criticadas e ambas não pude ver..

O @salaboy abriu o evento com um keynote sobre jBPM5 seguido do @jedgarsilva, com toda sua manha de fazer apresentações, falando sobre Cloud. O @porcelli e o Pedro Igor falaram sobre noSQL e data grids e se complementaram bem o primeiro dando um banho (muito bem dado) de conceitos e o segundo falando de produto mesmo, o Infinispan. Para mim foram as apresentações mais interessantes porque nunca tinha ido atrás desses assuntos, que já estão há um bom tempo ai como buzzwords.

Uma apresentação que eu queria muito ter visto e perdi foi a do @jpviragine falando sobre Federação de Dados com o Teiid. No horário da apresentação dele eu estava na outra sala falando sobre JBoss Portlet Bridge. Uma pena, ainda mais vendo a boa repercussão que teve =/

Teve também Weld e Seam com o @rimolive e a @hannelita, que cobriram muito bem o assunto. O @rafabene e o @osmanlira mandaram muito bem na apresentação de Drools. O @rafaeltuelho falou sobre RHQ, com uma demo que pelo que ouvi foi massa. E restou à Flávia Rainone fechar o evento falando sobre JBoss7.

O evento foi nota 10, mesmo sendo apenas a primeira edição em Brasília. Fiquei muito feliz de ter podido palestrar nele porque o público estava muito interessado e não tem nada melhor do que ver gente interessada perguntando na sua palestra =)

Aos que não foram, recomendo não perderem a chance de se inscrever para a edição de 2012 já já deve tá vindo ai.

Cheers!

Se você quer utilizar o GateIn com Tomcat é um pouco mais complicado, mas nada preciso adicionar a instalação do Tomcat do GateIn normalmente fazer algumas alterações:

1. Mudar no “Server Location” para “Use Tomcat installation (takes control of Tomcat installation)”

2. No  ”Launch Configuration” configurar o “Working directory” com o $TOMCAT_HOME

3. Ainda no  ”Launch Configuration” adicionar os parâmetros:

-Djava.security.auth.login.config=../conf/jaas.conf

-Dexo.conf.dir.name=gatein/conf

4. Provavelmente será também preciso alterar limites de memória da JVM e timeouts de subida/descida do WTP.

Para desenvolver no GateIn, tanto no JBoss quanto no Tomcat, pode ser interessante adicionar o parâmetro -Dexo.product.developing=true, que desabilita vários caches e desabilita o merge/compressão de CSS e JS.

No entanto nós do cluster apenas aceitam mensagens de nós que façam parte da sua view, o que pode trazer problemas. Imagine um cluster com view V1={A,B,C} e um novo nó D que entra no cluster. Quando a nova view V2={A,B,C,D} é instalada no nó D, os outros nós A, B e/ou C podem ainda ter a view V1 (views são instaladas sem ordem específica). Isso quer dizer que eles  vão descartar mensagens enviadas por D, já que ele não faz parte do cluster (porque a view V2 ainda não foi instalada).

Para isso é possível usar o protocolo FLUSH [1] (já existe uma configuração padrão no JGroups chamada flush-udp.xml) que resolve o problema de outros nós não terem a mesma view do nó que enviou a mensagem. No entanto é preciso subir outra thread ao enviar mensagens com o FLUSH no view Accepted() [2].

Referências
[1] http://www.jgroups.org/manual-3.x/html/user-channel.html#Receiver
[2] http://community.jboss.org/wiki/SendingOfMessagesInViewAcceptedCallback

Com a padronização numa JSR, agora implementações CDI são obrigadas a suportar uma variedade maior de ambientes de forma vendor neutral. O Weld faz isso e entre os ambientes suportados está o Tomcat. Portanto não há necessidade de configurações extras e gambiarras! O próprio projeto Weld provê archetypes maven com várias configuração, para criar uma aplicação para rodar em um servlet container:

mvn archetype:generate -DarchetypeArtifactId=weld-jsf-servlet-minimal \
                       -DarchetypeGroupId=org.jboss.weld.archetypes \
                       -DarchetypeVersion=1.0.0.Beta1 \
                       -DarchetypeRepository=central

E um projeto pronto para ser executado no Tomcat/Jetty será criado. O problema é que, devido a um bug, no Tomcat 7 pode ser que você veja a seguinte exceção:

SEVERE: Exception sending context initialized event to listener instance of class org.jboss.weld.environment.servlet.Listener
java.lang.NoClassDefFoundError: org/apache/AnnotationProcessor
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2820)
	at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1143)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1638)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1516)
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2820)
	at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1143)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1638)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1516)
	at org.jboss.weld.environment.tomcat.Tomcat6Container.initialize(Tomcat6Container.java:47)
	at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:184)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4544)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5016)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:140)
	at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1035)
	at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:738)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:140)
	at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1035)
	at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:289)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:140)
	at org.apache.catalina.core.StandardService.startInternal(StandardService.java:442)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:140)
	at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:674)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:140)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:596)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:616)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:303)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:431)
Caused by: java.lang.ClassNotFoundException: org.apache.AnnotationProcessor
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1671)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1516)
	... 36 more

O problema é que o Weld identifica erroneamente o Tomcat 7 como Tomcat 6. Para resolver o problema podemos definir explicitamente que o container que estamos usando é o Tomcat 7. Isso é feito criando-se um arquivo META-INF/services/org.jboss.weld.environment.Container no classpath com o conteúdo:

org.jboss.weld.environment.tomcat7.Tomcat7Container

Note que estamos definindo na mão o container! Ou seja, abrimos mão da portabilidade. Vamos esperar o bug ser corrigido, mas até lá é isso!

Referência: https://issues.jboss.org/browse/WELD-879

Introdução (ou como era com o JBossMQ)

Antigamente, o JBossMQ já era clusterizável (ouch.. neologismo..) mas conseguia isso usando o HA Singleton do JBoss. O JBoss quando configurado em cluster pode ser serviços deployados (ouch de novo..) como singletons através do cluster. Funciona assim: você diz ao JBoss que aquele serviço é um HA Singleton e o JBoss vai garantir a você que em seu cluster haverá sempre um, e apenas um, serviço ativo no cluster (enquanto restar nós no cluster, claro). Essa é uma funcionalidade muito interessante pois permite serviços cluster unaware serem clusterizáveis.

O balanceamento de carga pudia ser feito através dos consumidores: implementando um ReceiverImpl consumidores iriam receber as mensagens a la round robin. Melhor que nada.

JBoss Messaging

O JBoss Messaging é a implementação padrão do JBoss 5. Com o JBoss Messaging a infraestrutura de clusterização melhorou Muito. Podemos agora criar um cluster ativo/ativo, que quando um nó falhar o outro se encarregará de enfileirar suas mensagens. E ainda mais, temos balanceamento de carga de fato: cada conexão aberta usará uma fila diferente, round robin way.

Montando o cluster

Configurar o JBoss Messaging em cluster é extremamente fácil:

• Ative a clusterização nos arquivos de configuração do JBoss Messaging e configure um banco de dados compartilhado;
• User um ConnectionFactory e uma Queue/Topic marcados como clusterizados.

Bom, vamos aos bits. As versões usadas seguem:

• JBoss 5.1.0.GA
• JBoss Messaging 1.4.3.GA (a que vem por padrão)

Configurando o JBoss Messaging

Para fazer o failover, o JBoss Messaging precisa usar um banco de dados compartilhado. Copie de $JBOSS_HOME/examples/config o XML apropriado sobrescrevendo o $JBOSS_HOME/server/all/deploy/messaging/hsqldb-persistence-service.xml (lembre de configurar/iniciar o banco de dados!). Vou usar o MySQL:

rm $JBOSS_HOME/server/all/deploy/messaging/hsqldb-persistence-service.xml
cp $JBOSS_HOME/examples/config/mysql-persistence-service.xml $JBOSS_HOME/server/all/deploy/messaging

Ative a clusterização:

<attribute name="Clustered">true</attribute>
<attribute name="FailoverOnNodeLeave">true</attribute>

Aponte para apontar para o datasource do seu banco:

<attribute name="DataSource">java:/DefaultDS</attribute>

Criando as filas e factories

Vamos usar o ClusteredConnectionFactory, que é uma factory padrão do JBoss que vá vem configurada em cluster, se quiser ver como é feito: $JBOSS_HOME/server/all/deploy/messaging/connection-factories-service.xml.

Só precisamos criar nossas filas clusterizadas. Adicionem um arquivo $JBOSS_HOME/server/all/deploy/clustered-destinations-service.xml com o seguinte conteúdo:

<?xml version="1.0" encoding="UTF-8"?>
 
<server>
 
   <mbean code="org.jboss.jms.server.destination.QueueService"
      name="jboss.messaging.destination:service=Queue,name=clusteredQueue"
      xmbean-dd="xmdesc/Queue-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="Clustered">true</attribute>
   </mbean>
 
</server>

Criando os profiles

Se queremos criar um cluster vamos precisar de dois nós! Então copie o profile all e crie dois outros profiles:

cp -r all jms1
cp -r all jms2

Testando

Vamos subir os dois nós usando o serviço de ServiceBinding do JBoss para não haver conflitos de porta ou ip:

./run.sh -c jms1 -Djboss.service.binding.set=ports-01 -Djboss.messaging.ServerPeerID=1
./run.sh -c jms2 -Djboss.service.binding.set=ports-02 -Djboss.messaging.ServerPeerID=2

Agora vamos usar uns programinhas que fiz para produzir e consumir mensagens, ele é bem simples e intuitivo e é empacotado junto com os fontes. Vamos usá-lo para testar nosso cluster.

Iniciamos um consumer para cada nó do cluster:

java -cp JmsSample.jar:$JBOSS_HOME/client/jbossall-client.jar net.rafaelliu.jms.JmsConsumer 127.0.0.1:1100 ClusteredConnectionFactory queue/clusteredQueue
java -cp JmsSample.jar:$JBOSS_HOME/client/jbossall-client.jar net.rafaelliu.jms.JmsConsumer 127.0.0.1:1200 ClusteredConnectionFactory queue/clusteredQueue

E iniciar o nosso producer:

java -cp JmsSample.jar:$JBOSS_HOME/client/jbossall-client.jar net.rafaelliu.jms.JmsProducer 127.0.0.1:1100,127.0.0.1:1200 ClusteredConnectionFactory queue/clusteredQueue 10 1 "Mensagem de teste"

Viram que as mensagens foram balanceadas? Agora podemos tentar o seguinte:

• fechar um dos consumers: as mensagens são enviadas para o outro consumer;
• fechar um dos consumers enquanto estão sendo enviadas mensagens: o outro consumer assume a partir da última mensagem;
• pausar e despausar um consumer: as mensagens vão sendo enfileiradas e quando despausamos, elas são todas consumidas;
• pausar um consumer e depois fechar: as mensagens vão sendo enfileiradas e quando fechamos, elas são repassadas para o outro nó.

Dá pra brincar muito!

Futuro

Atualmente, sendo empacotado junto com o último Milestone do JBoss 6, o serviço de mensageria foi trocado pelo HornetQ. Isso significa ainda outra evolução na área do MOM para a JBoss. Vamos ver se quando for para GA não escrevo sobre ele. Até a próxima o/

PS: para produção dêem uma olhada nos parâmetros DefaultPreserveOrdering e SuckerPassword.

Binário: http://github.com/downloads/rafaelliu/rafaelliu.net/JmsSample.jar

Foram abertas as incrições para o JBoss In Bossa 2010 que acontecerá em São Paulo dias 7 e 8 de maio. O evento é o maior da América Latina relacionado a JBoss e contará com a presença de palestrantes internacionais como o Peter Muir (project lead do Seam e do Weld), Benjamin Mestrallet (CEO da eXo Platform) e Mauricio Salatino (CTO da PlugTree).

Veja alguns dos principais assuntos previstos na agenda:

• O novo JBoss 6
• Tuning JBoss
• Java Persistence API
• Seam
• Weld
• Contexts and Dependency Injection
• Java ServerFaces 2.0
• Teiid
• Drools
• Jopr
• E a lista continua..

É uma ótima oportunidade para conhecer pessoalmente alguns nomes de peso na comunidade e fazer networking. Se inscreva!

Acompanhe também o evento via @jbossinbossa.

This one goes to people using JBoss Portlet Bridge 2.0.0.CR1 (don’t know about other versions). The stacktrace is the following:

 Caused by: java.lang.IllegalArgumentException: LifecycleId already added for id: SEAM_PORTLET.
         at com.sun.faces.lifecycle.LifecycleFactoryImpl.addLifecycle(LifecycleFactoryImpl.java:199)
         at org.jboss.portletbridge.lifecycle.PortletLifecycleFactory.addLifecycle(PortletLifecycleFactory.java:60)
         at org.jboss.portletbridge.lifecycle.PortletLifecycleFactory.(PortletLifecycleFactory.java:48)
         ... 195 more

The long history:

Portlet Bridge uses a custom JSF Lifecycle for handling behaviour specific to portlets. It does so by means of a embedded faces-config.xml in it’s jar. The problem is that it tries to add this SEAM_PORTLET even if it already exists. That means that having 2 Portlet Bridges JAR in your application’s classpath will cause confusion.

That raises a not so trivial scenario. Even tho you have only one Portlet Bridge JAR, depending on how your JBoss classloading configuration is set, this Exception can occur. That’s because JBoss uses temporary folders to unpack Javar Archives in it’s <JBOSS_HOME>/server/default/tmp (or whatever configuration you are using). These folders have unique auto-generated names, so between startups your WAR may be unpacked to a folder in tmp while there’s already an older version there with a different name.

The short history:

Delete your JBoss configuration’s tmp and work (don’t worry, it’s safe) folder or search for some duplicated portletbridge-impl.jar.

Reference: JIRA

O JBossInBossa 2010 é a conferência anual da comunidade JBoss brasileira, ele contará com palestrantes internacionais que são líderes de projetos opensource, bem como palestras da comunidade brasileira que desenvolve e fomenta tecnologias relaciodas além do time brasileiro JBoss que atua em diversos projetos de missão crítica que usam tecnologias de ponta em projetos em todos os lugares do Brasil.

Mais informações: JBossInBossa