E outra… não tinha um papo que o tomcat tinha convertido alguns conectores para nativos do s.o ?
http://weblogs.java.net/blog/opinali/archive/2005/10/tomcat_goes_nat.html
Nada contra o Glassfish, mas não vejo nenhum motivo especial para usá-lo. Precisamos apenas de um servlet container, e a solução que chegamos está melhor do que o que precisariamos.
Quanto ao connector nativo do tomcat, já estávamos até usando. O problema era o consumo alto de memória que o tomcat estava tendo, levando a OutOfMemoryError depois de algum tempo.
Suspeitávamos de algum vazamento de memória no código do guj/jforum2, mas como não se manifestou denovo ainda com tudo rodando no jetty, começo a suspeitar do próprio tomcat, ou de alguma configuração errada que tivessemos.
O problema de memória parece estar solucionado. Mas se voltar a aparecer vamos ter que fazer um profiling mais profundo… (e eu quero fugir o máximo disso).
E se não “vier a usar”? Pra quê pagar o preço da ferrari? 
Fábio, nesse caso os conteúdos estáticos estão relacionados ao Guj e não ao JForum, certo?
Naverdade, conteúdo estático toda aplicação tem, por exemplo figuras, e no caso do JForum isso não é diferente. Algumas empresas, como M$, Google, UOL, enfim, até usam servidores de imagens para centralizar esse conteúdo:
Ex:
http://img0.gmodules.com/ig/modules/youtube_videos_content/ytlogo_51x22.gif
por ae vai…
Vcs dividem a aplicação do JForum entre conteúdo estático e conteúdo dinâmico? Fisicamente dizendo, as figuras do JForum estão fora da aplicação?
[quote=Fabio Kung]
Para fazer o papel de proxy reverso, estamos usando o fantástico Nginx. É realmente impressionante. Recomendo que dêem uma olhada. É muito rápido e consome poquíssimos recursos do servidor. Senti que o GUJ está bem mais rápido agora com o nginx servindo o conteúdo estático.[/quote]
O que vcs usavam antes? Httpd Apache?
[quote=Fabio Kung]
Também fizemos uma tentativa de deixar vários jetties em balanceamento de carga de ontem para hoje. Funcionou bem, a não ser pelo fato de que o jforum do jeito que está configurado hoje não consegue compartilhar os caches que faz entre os vários nós (jetty) de um cluster. Com um pouquinho mais de código e configuração daria para balancear carga sem problema, mas com o número de requests/s e o uso dos recursos no servidor atuais, não estamos precisando mesmo de balanceamento de carga para o GUJ.[/quote]
Acredito que vc deva manter o balanceamento, pois oferece redundância, facilidades na atualização, manutenção dos servidores, enfim.
Parabéns pelo trabalho!
[]'s
Luiz
Ao JFórum também.
Isso faria muito sentido sim Luiz, se tivéssemos carga suficiente para precisar de um cluster de verdade. O guj roda hoje em apenas uma máquina, não há porque servir o conteúdo estático de outro servidor.
Antes não tinha nenhum proxy reverso. Apache httpd + mod_proxy ou mod_jk era sim uma opção, mas a muito tempo eu queria botar o nginx para funcionar de verdade. Essa foi a grande chance.
Denovo, concordo plenamente com você, se o GUJ precisasse de várias máquinas para atender o número de requisições que temos hoje. Não precisamos de balanceamento de carga hoje, por isso não vale o custo (tempo) para colocar isso no ar.
Obrigado pelos comentários!
Então esta explicado pq, mesmo com meu roteador engasgando as vezes, o GUJ ficou mais rápido. :lol:
Fábio, com relação aos servidores de imagens. O que vc acha? Vc acha interessante separar as imagens da aplicação?
Vamos supor que o Guj tivesse um servidor de imagens (images.guj.com.br) vc colocaria as imagens do JForum nesse servidor?
O JForum trabalha com internacionalização, onde existem várias imagens relacionadas aquele idioma, enfim. Resumidamente, caso eu queira adicionar um idioma novo, vou precisar criar as imagens e properties para aquele idioma. Então, no momento do deploy desse idioma vou precisar colocar as imagens em um servidor, nesse caso images.guj.com.br, e as propriedades em outro, vamos supor jforum.guj.com.br? Fica meio trabalhoso isso. É uma dificuldade a mais q vc cria, certo?
Acredito que esses servidores de imagens sejam ideais para armazenar imagens que devam ser acessadas por vários domínios. Suponha que eu tenha uma grande rede de supermercados e queira que todos os sites sigam o mesmo layout de imagens. Esse caso seria interessante criar um servidor de imagens.
Aqui na empresa trabalhamos com httpd+mod_proxy. Estou pensando em usar o mod_cache para trabalhar com as imagens da aplicação. Basicamente:
front-end: httpd+mod_proxy+mod_cache
middle-end: servlet-container
back-end: EJB
database: sgbd
Quero que as imagens existentes no middle-end (aquelas específicas daquela aplicação, como JForum) sejam armazenadas em cache no fron-end.
Ainda estamos acertando algumas coisas, mas acredito que o caminho seja esse. O que vc acha?
[]'s
Luiz
No caso do guj, mesmo se tivéssemos necessidade de mais servidores, eu acho que não separaria as imagens. Só faria isso se precisasse guardar as imagens em um servidor especial para isso: ou mais próximo (menor latência) dos usuários finais, ou então porque as imagens ficam guardadas em algum tipo de storage. A necessidade de separar as imagens em outro(s) servidor(es) costuma ser bem específica de cada caso. É rara a necessidade para os casos comuns.
Perfeito. Como você mesmo mostrou, uma necessidade específica.
[quote=Luiz Henrique Coura]front-end: httpd+mod_proxy+mod_cache
middle-end: servlet-container
back-end: EJB
database: sgbd
Quero que as imagens existentes no middle-end (aquelas específicas daquela aplicação, como JForum) sejam armazenadas em cache no fron-end.
Ainda estamos acertando algumas coisas, mas acredito que o caminho seja esse. O que vc acha?[/quote]
Não gosto de ficar dando muito pitaco nas arquiteturas dos outros. Vocês tem o próprio motivo para terem feito essa escolha. Mas como vc pediu a minha opinião, não acho que o mod_cache traria muita vantagem para as imagens, já que serve basicamente para cachear conteúdo dinâmico. Geralmente você salva o cache em disco mesmo, para não ter que renderizar (e processar) o conteúdo dinâmico toda vez. Ler o cache do disco, ou ler a imagem do disco daria na mesma; a não ser que você deixe o mod_cache guardar as coisas na memória, sacrificando memória no servidor. Realmente não sei se valeria a pena, já que um bom filesystem deveria eliminar essa necessidade de deixar as imagens na memória e o seu gargalo de performance com certeza não vai estar aí.
Você já tem o mod_proxy, então acredito que fazer o httpd servir as imagens, sem precisar chegar ao middle tier (servlet container) já é mais do que suficiente. Além disso, você pode customizar o mod_proxy para fazê-lo setar os headers da resposta HTTP e mandar os browsers manterem as imagens cacheadas por mais tempo.
ps.: a nova arquitetura tem resistido MUITO bem. Em breve posto algo no blog da Caelum explicando os resultados direitinho; o porquê do GUJ estar “voando” recentemente!
(ansioso pelo guj3)
E o Jetty rodando no Eclipse com WTP?
alguem ja conseguiu usar?
eu tentei uma vez o Jetty WTP adapter
http://yuna.ultimania.org/wiki/2006/11/05/23.56
mas nao consegui, entao o jeito era usar aquele jetty launcher mesmo… mas assim não da de utilizar algumas coisas bacanas que o WTP tem
não querendo ser chato, e nada contra o jetty.
mas eu acredito que o glassfish seja melhor para o GUJ, pelo fato de você poder clusterizar ele com diversos servidores, balanceamento de cargas, facil configuração, ejb, webservices, JMS, tera suporte a JavaEE6, blablabla e etc…
agora o jetty eu nunca usei, poderia dizer quais são as vantagens.
abraço.
No tópico sobre o eclipse 3.4 ganymede, me parece que tem um post sobre alguem usando o jetty no novo WTP.
Olá
Fábio, este tópico ficou muito bom e bastante esclarecedor. Vou colocar uma resposta só para poder receber emails sobre a discussão.
Gosto do Glassfish e justamente no momento estou trabalhando com o Grizzly.
Pelo que foi escrito nos posts anteriores, acho que isto aqui ficou completamente Off Topic.
[]s
Luca
[quote]leandrokjava wrote:agora o jetty eu nunca usei, poderia dizer quais são as vantagens. [/quote]Se vc. não fez uma avaliação real das necessidades do projeto e nem conhece ou usou outros servlets containers, como pode sugerir o glassfish como uma melhor solução.?.
graças a este tópico, resolvi apostar no jetty e andei fazendo uns testes de performance…
muito simples, me surpreendeu muito em relação ao glassfish… 
e também ando vendo o Nginx…
Fabio, não dava para fazer um post ou nesta thread mesmo colocar um exemplo da configuração do Nginx com o Jetty, precisa suar o AJP?
e para as pools usou o bitronix?
meu querido.
acho que tu não me entendeste, conheço muitos outros containers, e do meu ponto de vista o glassfish seria uma opção legal, como muitos outros integrantes do Guj comentaram.
mas esqueça isso.
a minha real pergunta, é quais são as vantagens do jetty, sem comparam com o glassfish, esquece ele.
quero saber o que o jetty tem, ele é realmente igual ao tomcat? tem algo a mais? etc…
compreende?
[quote=eduveks]graças a este tópico, resolvi apostar no jetty e andei fazendo uns testes de performance…
muito simples, me surpreendeu muito em relação ao glassfish… :P[/quote]
Não tenho nada a ver com a Mortbay, mas sempre fui entusiasta do Jetty. Ótimo saber disso!
Tem muita gente pedindo. O próximo post dessa “série” no blog da Caelum vai ser sobre load-balancing, daí eu posto alguns exemplos de configuração sim.
Não usei AJP. O proxy reverso encaminha as requisições via HTTP mesmo, como faria o mod_proxy no Apache Httpd.
Não usei. Estamos usando o C3P0 mesmo. Não tive oportunidade ainda de testar o bitronix, mas parece bem legal sim. Ainda mais se estivéssemos precisando de um TransactionManager (JTA).
Valeu pelas dicas!
Aqui tem bastante coisa sobre as vantagens do jetty, o que ele tem, etc: http://www.mortbay.org/jetty-6/
Ele também é um servlet container, assim como o Tomcat. Do meu ponto de vista, o que mais agrada no Jetty é o fato de ele ser facilmente embutível e de ser relativamente leve, se comparado a outros containers.
Foi um dos pioneiros a usar conectores NIO também, e isso fez o meu interesse despertar a um bom tempo. Hoje em dia isso não conta muito, já que todos os servlet containers possuem conectores NIO.
Mas eu não sou xiita, como ninguém deveria ser. Eu sempre digo que não existe melhor tecnologia. Meio massante repetir isso sempre, mas a melhor escolha sempre vai depender do contexto. Gosto do jetty, mas sei que não é para ser usado sempre.
A resposta curta é: o jetty não da memory leak com o GUJ
Aqui tem bastante coisa sobre as vantagens do jetty, o que ele tem, etc: http://www.mortbay.org/jetty-6/
Ele também é um servlet container, assim como o Tomcat. Do meu ponto de vista, o que mais agrada no Jetty é o fato de ele ser facilmente embutível e de ser relativamente leve, se comparado a outros containers.
Foi um dos pioneiros a usar conectores NIO também, e isso fez o meu interesse despertar a um bom tempo. Hoje em dia isso não conta muito, já que todos os servlet containers possuem conectores NIO.
Mas eu não sou xiita, como ninguém deveria ser. Eu sempre digo que não existe melhor tecnologia. Meio massante repetir isso sempre, mas a melhor escolha sempre vai depender do contexto. Gosto do jetty, mas sei que não é para ser usado sempre.[/quote]
hum…
Ele tem facil integranção com JOnAS , Geronimo , JBoss.
legal, gostei mesmo.
gostei disso.
muito obrigado pelo esclarecimento fabio.
abraço.