MouseOver Studio

Quando trabalhamos com aplicações web é muito comum salvar dados nas sessões dos usuários. No caso que estejamos trabalhando também com cluster, a melhor opção na maioria das vezes é replicar as sessões em todas as instancias do nosso servidor de modo que os usuários possam se conetar em qualquer nodo do cluster e a sessão este disponível para eles em tudo momento.

Talvez tenham se perguntado: qual é a outro opção? Bom, a outra opção e utilizar “sticky sessions”, de modo que o balanceador sempre se conete com o mesmo membro do cluster, o qual possui a sessão do usuário. O ruim das sticky sessions é que ao cair algum nodo do cluster, os dados que se encontravam neles serão perdidos dado que não foram replicados.

Nesse artigo vamos configurar nossa aplicação web para que o JBoss 4.2.2.GA replique a sessão HTTP ao longo de todos os nodos do cluster cade vez que ela sofrer alguma alteração. A configuração é realizada no JBoss Web que utiliza o Tomcat, pelo que a configuração num Tomcat independente não deveria fugir muito do que ira ser mostrado aqui.

Mãos na obra

A configuração é bem simples, são necessários somente dois passos.

O primeiro passo é indicar que nossa aplicação é distribuída. Possivelmente esta configuração já foi feita devido a que estamos supondo que a aplicação já foi configurada para rodar num cluster. De qualquer modo, a configuração é realizada no arquivo web.xml da aplicação; devemos inserir o seguinte trecho dentro do nodo web-app:

<distributable />

O segundo e último passo é configurar um arquivo chamado jboss-web.xml, que sera localizado na pasta WEB-INF. Esse arquivo indicara ao JBoss como e quando replicar a sessão da aplicação:

<jboss-web>
<replication-config>
<replication-trigger>SET</replication-trigger>
<replication-granularity>SESSION</replication-granularity>
</replication-config>
</jboss-web>

O nodo replication-trigger indica quando o JBoss deve replicar os dados. Nesse caso estamos indicando que os dados devem ser replicados cada vez que seja chamado o método setAttribute da sessão (HttpSession).

O nodo replication-granularity indica o que devera ser replicado. Se a sessão não for muito grande, SESSION é uma boa opção porque sera replicada a sessão inteira. Quando a sessão é grande demais, a opção ATTRIBUTE resulta num ganho de performance devido a que somente serão replicados os atributos da sessão que sofreram alteração.

Testando a configuração

Fiz uma aplicação web bem simples para poder testar e comprovar que o JBoss esta replicando os dados da sessão dela. A aplicação guarda na sessão o número de acesos e printa o valor na tela. Cada vez que acessarmos a aplicação, deveria aparecer quantas vezes realizamos a operação, independente de qual nodo do cluster o balanceador escolher para servir.

A aplicação pode ser descarregada de aqui .

Para finalizar, agora o blog possui uma pagina de contato. Qualquer duvida ou pergunta que não quiserem colocar nos comentários pode ser enviada mediante o formulário e eu responderei assim chegar na minha caixa de email.