| Autor |
Mensagem |
|
|
f4314n0 wrote:Oi Andre, tudo bem?
To tentando chegar onde voce ja conseguiu chegar: usar vraptor 3.4.1 com jboss, porem na versao as7.
Voce ta deixando o controle de transações com o jboss? Funciona bem em cluster?
Confesso que estou levando uma surra pra conseguir configurar esse ambiente.
Obrigado.
Estou deixando o controle de transação com o container sim. Na verdade nem me preocupo com isso, minha aplicação usa beans stateless e deixo tudo default, não alterei nada do comportamento padrão. Está funcionando como sempre. Em cluster ou não, funciona do mesmo jeito.
Sempre subo a aplicação web e o ear junto na mesma instancia do jboss então ele sempre pega os beans localmente.
Também não estou fazendo load balance de EJBs. Então sinceramente não sei se isso poderia afetar o comportamento, creio que não.
Com jboss 7 nunca testei, sei que mudou muita coisa em relação ao 6. Estou esperando ficar mais estável para poder começar uns ensaios com ele.
|
 |
|
|
Pessoal, consegui descobri a causa do problema.
Achei a discussão abaixo:
http://tomcat.10.n6.nabble.com/distributable-mode-does-not-work-with-Servlet-3-0-td4487088.html
Parece que o tomcat (o jboss usa o tomcat como container web) precisa que todos os web-fragments.xml sejam annotados com <distributable/> senão nada feito, ele não fará a replicação da sessão. Como o web-fragment do vraptor não tem o distributable setado ele interpreta que não pode "distribuir" a aplicação. De fato foi só anotar o web-fragment do vraptor como <distributable/> e tudo funcionou perfeitamente.
Obrigado Lucas pela ajuda!
|
|
|
|
Sim, Lucas, eu vou fazer esses testes a seguir. Como disse, nao fiquei contente de ter mechido no jar do vraptor. Quero testar uma forma de fazer funcionar sem precisar dessa alteração. Mas como disse estou desconfiando de ter incluido um jar na aplicação que fez alterar o parser XML, e isso está gerando o problema. Quero fazer os testes certinho, e volto a dar um retorno aqui para tentar contar o final da história... 
|
|
|
|
Pessoal, problema resolvido, como o Lucas havia falado o pico não funciona muito bem para o cluster. Com o guice funcionou perfeitamente.
Só tem uma bizarrice a mais que to achando que é com o jboss. Quando troquei para o guice container começou a dar um erro de parser no XML web-fragment.xml dentro do META-INF do jar do vraptor. Minha aplicação está usando web-app na versão 2.5 ainda, então ainda uso web.xml, old school, e o vraptor já usa versão 3.0. Não sei se o jboss se perdeu, mas retirei o web-fragment de dentro do jar e funcionou perfeito. Mas ainda não estou satisfeito com o resultado, não queria ter mechido no jar do vraptor, isso me parece POG demais. Estou desconfiando das minhas libs, pois uso hibernate e hibernate-search. Mais precisamente dessa aqui: xml-apis-1.0.b2.jar
Estou pensando que ela possa ter sobrescrito o comportamento padrão do parser que ja existia no jboss. Bem, continuo investigando de qualquer forma.
|
|
|
|
|
Obrigado pela dica Lucas, vou fazer os testes e posto aqui os resultados.
|
|
|
|
|
Estu usando com pico.
|
|
|
|
Pessoal, estou me deparando um probleminha bem esquisito. Configurei um cluster de jboss 6.1.0, e minha aplicação está usando Vraptor 3.4.1. O que ocorre que não estava conseguindo replicar minha sessao para os nós do cluster de jeito nenhum, então criei uma classe bem besta só pra testar a aplicação:
Bem, quando coloco ela em um projeto web que só contém essa classe e o web.xml, a replicação funciona perfeitamente:
Quando coloco a mesma classe no meu projeto, nada feito. Não funcionada a replicação de sessão.
Bem, acontece que eu comecei a desconfiar de tudo e de todos, foi ai que pensei em retirar o Vraptor do class-path, e então a classe de teste passou a funcionar perfeitamente.
Alguém tem alguma ideia do motivo?
[]s
|
|
|
|
vargas wrote:Acho que a dúvida dele não é se deve ou não usar EJB, e sim o lugar das regras de negocio que na minha opinião não devem ficar nos EJBs (ou seja lá o que vc vier a usar no servidor), mas sim classes java comum que são distribuídas em pacotes jar.
Bem, se essa é a dúvida então eu ainda acho que EJBs são melhores. Distribuir jars é um inferno, vocês sabem. Quando se tem 3 ou mais sistemas pra manter isso começa a ficar inviável se você tem manutenções praticamente toda semana. Pelo problema que eles explicou, creio que o uso de EJBs inicialmente já irá impedi-lo de cair em problema como distribuição de jars, o famoso jar hell!!!
O que o xdraculax comentou é muito interessante. É importante resolver os problemas que você tem agora. Mas, xdraculax, acho que pelo que ele explicou já é o caso de usar interfaces remotas sim. Ele mencionou o uso das entidades de negocio por vários sistemas. A não ser que eu tenha entendido errado...
|
|
|
|
vitorh.campos wrote:Olá,
Como assim
Então a dúvida é: vale a pena usar Session Beans para manter as regras de negócio, é melhor mantê-los nas próprias aplicações
Acho que me expressei mal. O que eu quis dizer foi: vale a pena manter as regras de negócio em Session Beans e fazer as chamadas nas aplicações, ou é não usar Session Beans manter as regras dentro de cada uma dessas aplicações? Ou há alguma outra maneira de se compartilhar código entre aplicações?
Vitor tenha certeza: use EJBs sim!
Seu caso pelo que descreveu é um caso classico de uso de EJBs. Eles te proporcionarão muitos beneficios. Pelo que vi você conhece, sabe para que servem, sabe aplicar, mas só está inseguro em usar. Então vá em frente. Separe sua logica de negócio em beans.
|
|
|
|
paulo1911 wrote:Ola amigo,
Leia sobre os @PostConstruct @PreDestroy @PrePassivate, Interceptors tb pode ajudar. Entretanto pq vc nao conseguiu conversar entre as aplicações?
Qual seria o caso?
Ja pensou em serviços em Rest?
Fallow
Ah sim, esqueci de dizer. Não posso alterar os beans na aplicação. Por alguns motivos, mas a solução precisa ser externa aos beans EJB. Devem até mesmo rodar separadamente, fora do conteiner.
|
|
|
|
|
Acho que a persistência você configura no container. Ela pode ser durável e persistir em memoria, disco, banco. Se será em memoria ou disco por exemplo você configura no conteiner. O Jboss por exemplo persiste em disco de uma forma muito bacana e bem otimizado já. Se o sistema for linux, melhora ainda mais.
|
|
|
|
paulo1911 wrote:Ola amigo,
Leia sobre os @PostConstruct @PreDestroy @PrePassivate, Interceptors tb pode ajudar. Entretanto pq vc nao conseguiu conversar entre as aplicações?
Qual seria o caso?
Ja pensou em serviços em Rest?
Fallow
Não consegui achar uma aplicação que faça monitoração e converse com a aplicação que precisa ser avisada. É um aplicação legada, interna da empresa, então tem toda uma maneira de conversar com ela usando XML. Por isso estou criando um aplicativo de monitoração.
|
|
|
|
braian wrote:Estou trabalhando/estudando em um projeto EJB que usa filas e tópicos (persistidos) e agora preciso retirar persistência do tópico.
Motivo: O MDB que lê do tópico persistido está muito lento pois muitos registros são gravados em pouco tempo.
Como funciona:
1 - Existe um processo que manda mensagens para uma fila...
2 - Essa fila encaminha a mensagem para um tópico persistido que será consumido por outro MDB.
Problema:
1 - Demora pra consumir os dados do tópico.
Proposta:
1 - Pensei em retirar o tópico persistido e colocar em filas (vão ser consumidas mais rapidamente).
- Problema: Se um ouvinte cair ou até mesmo o servidor vou perder os dados pois os mesmos não serão mais persistidos (vou ter que correr o risco).
Dúvidas:
1 - Se um ouvinte da fila cair vou ter como recuperar a mensagem?
* O conceito de "Durable" serve também para queues?
- Como armazenar as informações em memória até que o ouvinte retorne e consuma o dado da fila.
2 - Qual o melhor a ser usado, filas ou tópicos (não persistidos, claro) e porque??????????????
Desculpe-me se fui idiota em algumas perguntas/dúvidas mais estou estudando a pouco tempo e preciso fazer isso o mais rápido possível.
Obrigado a todos.
braian, vou tentar te responder algumas coisas. Se estiver falando bobagem o pessoal ai me corrige.]
Usar fila ou tópico? Depende. A fila notifica apenas um consumidor. Quando um consumidor consumir a mensagem ela será extinta e ninguém mais lerá. É algo assim: quem ler primeiro leva. Não é indicado caso você precise fazer notificações para consumidores diferentes, que fazem coisas diferentes com essa mensagem. Vamos supor que voce tenha um sistema de cadastro, e quer informar que foi efetuado um cadastro pro seus sistemas de envio de email e de cobranca. Cada um teria um proposito diferente. Entao ambos devem ler a mensagem. Nesse caso a fila não é indicada, pois se algum dos consumidores ler a mensagem primeiro ela será eliminada da fila e o outro não a lerá. O tópico vem para justamente resolver esse problema. Entao se voce tem apenas um tipo de consumidor, e espera ter apenas esse tipo de consumidor no futuro proximo, use filas. Caso contrário use tópicos.
Durable serve para filas também. Mas lembre-se do que eu disse: quem ler primeiro leva, entao a mensagem será considerada descartada.
braian wrote:- Como armazenar as informações em memória até que o ouvinte retorne e consuma o dado da fila.
Quanto a isso não se preocupe, o container fará isso pra voce. A mensagem ficará disponivel até que alguem leia. No caso de uma fila. No caso do tópico ela ficará disponivel para que todos os consumidores a leiam. Não estou certo mas acho que existe um tempo máximo em que essa mensagem fica no tópico. Se nao me engano isso depende da implementação do container.
braian wrote:Proposta:
1 - Pensei em retirar o tópico persistido e colocar em filas (vão ser consumidas mais rapidamente).
- Problema: Se um ouvinte cair ou até mesmo o servidor vou perder os dados pois os mesmos não serão mais persistidos (vou ter que correr o risco).
Quanto a seu problema de performance, de uma olhada no seu hardware, de uma olhada na implementacao do container. De uma olhada em como está configurando essa persistencia. Tente otimizar ao maximo.
Verifique esse tipo de coisa antes de tomar a decisao de não persistir as mensagens. Se o seu nengocio requer esse tipo de persistencia, utilize-a. Pense bem antes de "correr riscos".
Espero ter ajudado!
|
|
|
|
|
Tenta quebrar o captcha! É muito complicado esse captcha?
|
|
|
|
ed78, para qualquer forma que você venha a utilizar, tome cuidado com os decompiladores.
Se partir para uma solução em que você escreve no aplicativo essa trava, decompilando seu código ficaria fácil de retira-la!
Eu já fiz manualmente, martelando no código mesmo. Simplesmente criei uma classe que executava um System.exit(0) caso o prazo tivesse expirado. Sei que é ridiculo, mas para o minha necessidade era suficiente.
|
|
|
|