Tem um tutorial no site da JBoss para configurar esse esquema de rodar 2 JBoss na mesma máquina.
Alguém aqui já utilizou esse ambiente ?
Dá para confiar isso em produção ?
Onde eu trabalho, temos 3 ambientes:
- Teste integrado;
- Homologação;
- Produção.
Cada ambiente é uma máquina virtual diferente.
Nos 3 ambientes, temos duas versões do JBoss: 4.0.2 e 5.1.0
Tem funcionado.
[],
AC
Ter máquina virtual no meu caso é inviável, não posso perder processamento para emular um novo sistema operacional.
Além disso, já tivemos tantos problemas com máquinas virtuais em alguns clientes, que os novos nem oferecemos mais a opção de usar VMWare, VirtualPC, VirtualBox.
A questão da máquina virtual é irrelevante, foi mais de curiosidade.
O ponto é que em cada máquina virtual tem duas versões do JBoss.
Nunca usei o Service Binding Manager do JBoss 5, mas já adotamos a mesma técnica de somar 100, 200, etc, às portas, mas de forma manual (alterando cada arquivo de configuração), com o JBoss 3.0. Chegamos a rodar 5 instâncias na mesma máquina de produção!
Quanto aos service locators, deixávamos as URLs (localhost:1099, localhost:1199, localhost:1299, etc) em arquivos de properties, de forma que não precisávamos refazer o build para fazer deploy em cada instância.
[quote=boaglio]
Tem um tutorial no site da JBoss para configurar esse esquema de rodar 2 JBoss na mesma máquina.
Alguém aqui já utilizou esse ambiente ?
Dá para confiar isso em produção ? [/quote]
Cara, atualmente estou tendo problemas com o balanceador e sticky session em um servidor de homologação.
Em produção é um cluster de dois nós em máquinas separadas, e funciona bem.
Certa vez trabalhei em uma empresa com suporte da JBoss, o próprio suporte comentou que o Cluster JBoss deve ser evitado. Muita complexidade e instalibidade (isso era na versão 4.3 GA), não sei como está hoje.
funciona bem, soh eh recomendado vc subir uma interface de rede diferente ao inves de trocar as portas.
[quote=pozzo]
Certa vez trabalhei em uma empresa com suporte da JBoss, o próprio suporte comentou que o Cluster JBoss deve ser evitado. Muita complexidade e instalibidade (isso era na versão 4.3 GA), não sei como está hoje.[/quote]
todo e qualquer cluster deve ser evitado se voce nao tiver necessidade pra ele, subir uma aplicacao simples em um cluster de jboss pra bonito eh burrice.
[quote=fmeyer][quote=pozzo]
Certa vez trabalhei em uma empresa com suporte da JBoss, o próprio suporte comentou que o Cluster JBoss deve ser evitado. Muita complexidade e instalibidade (isso era na versão 4.3 GA), não sei como está hoje.[/quote]
todo e qualquer cluster deve ser evitado se voce nao tiver necessidade pra ele, subir uma aplicacao simples em um cluster de jboss pra bonito eh burrice.
[/quote]
Isso é obvio. E não sei aonde comentei que era uma “aplicação simples”.
Bom, detalhando melhor minha resposta, o motivo dos problemas eram principalmente pela implementação do jgroups, que se perdia com muitos nós. E também o JMS em cluster, que não balanceava as mensagens de forma adequada.
Como eu disse, era uma versão mais antiga. Muito provavél que isso deva estar bem melhor na nova versão do JBoss. Mas, se puder evitar de usar JBoss em cluster, melhor (opinião pessoal).
Boa tarde, amigos.
Estou aproveitando esse post para colocar uma dúvida.
Estamos definindo a arquitetura de um sistema na qual estarei disponibilizando um serviço Java rodando em JBoss com SGBD PostgreSQL.
Não será um webservice e o consumo do serviço será via MQ a partir o WebSphere Message Broker.
Esse sistema será crítico e será necessário colocar mais de uma estância da aplicação/JBoss para dar conta do recado.
O problema é que o “infelizmente” o serviço será statefull (ok! podem me criticar) e estou quebrando a cabeça para descobrir uma forma de manter as sessões entre as várias instâncias do JBoss.
Até onde eu sei, dá pra fazer load balance no JBoss numa boa, porém, aí vem a minha dúvida:
"Como manter o estado daquele serviço compartilhado entre todas as instâncias do JBoss sem usar o SGBD para isso?"
Pensamos em usar uma hashtable para armazenar os dados, que serão muitos, mas não sei como mantê-la em todas as instância, já que o JBoss não faz necessariamente um Cluster.
Espero que tenha sido claro e agradeço a todos pela ajuda.
Aqui na empresa usamos, é bem estável.
Mas o que você realmente usa na sua empresa? Cluster ou só Load Balance no JBoss?
Todas as instâncias do servidor de aplicação compartilham da mesma sessão?
[quote=cesarpiau]Boa tarde, amigos.
Estou aproveitando esse post para colocar uma dúvida.
Estamos definindo a arquitetura de um sistema na qual estarei disponibilizando um serviço Java rodando em JBoss com SGBD PostgreSQL.
Não será um webservice e o consumo do serviço será via MQ a partir o WebSphere Message Broker.
Esse sistema será crítico e será necessário colocar mais de uma estância da aplicação/JBoss para dar conta do recado.
O problema é que o “infelizmente” o serviço será statefull (ok! podem me criticar) e estou quebrando a cabeça para descobrir uma forma de manter as sessões entre as várias instâncias do JBoss.
Até onde eu sei, dá pra fazer load balance no JBoss numa boa, porém, aí vem a minha dúvida:
"Como manter o estado daquele serviço compartilhado entre todas as instâncias do JBoss sem usar o SGBD para isso?"
Pensamos em usar uma hashtable para armazenar os dados, que serão muitos, mas não sei como mantê-la em todas as instância, já que o JBoss não faz necessariamente um Cluster.
Espero que tenha sido claro e agradeço a todos pela ajuda.
[/quote]
Pra fazer isso é muito simples, basta adicionar a tag no web.xml da aplicação e ser feito seu deploy no perfil all ou algum outro derivado dele.
[quote=pozzo][quote=fmeyer][quote=pozzo]
Certa vez trabalhei em uma empresa com suporte da JBoss, o próprio suporte comentou que o Cluster JBoss deve ser evitado. Muita complexidade e instalibidade (isso era na versão 4.3 GA), não sei como está hoje.[/quote]
todo e qualquer cluster deve ser evitado se voce nao tiver necessidade pra ele, subir uma aplicacao simples em um cluster de jboss pra bonito eh burrice.
[/quote]
Isso é obvio. E não sei aonde comentei que era uma “aplicação simples”.
Bom, detalhando melhor minha resposta, o motivo dos problemas eram principalmente pela implementação do jgroups, que se perdia com muitos nós. E também o JMS em cluster, que não balanceava as mensagens de forma adequada.
Como eu disse, era uma versão mais antiga. Muito provavél que isso deva estar bem melhor na nova versão do JBoss. Mas, se puder evitar de usar JBoss em cluster, melhor (opinião pessoal).[/quote]
Com certeza ocorreu aí um grande problema de comunicação. O problema não esta no jgroups, mas nas camadas onde ele atua, transporte e rede. O padrão que vem no servidor de aplicação é trabalhar sobre UDP com multicasting, o que pode ser bom para pequenas e redes e poucas instancias. Mas se sua rede apresenta problemas de latencia, perda de pacotes, não é isolada entre outras coisas, você deve alterar a configuração inicial para TCP. Com isso os problemas de comunicação entre os nodes desaparecerão e o cluster com jgroups+jbossCache não apresentará problema.