Fico contente que eu tenha ajudado.
Fico, também, um pouco espantado com o que aconteceu com o uso do Tomcat. Suportar apenas 3 usuários era uma coisa que não deveria acontecer. Tenho vários casos de desenvolvimento com o ambiente de produção baseado no Tomcat, onde um limite de usuários desta ordem de grandeza não acontece. Porém, pode existir algo implementado nos componentes que força este limite. Acho mais provável a limitação estar na programação dos componentes JSP ou Servlets do que no 'Web Container'. A idéia básica do Tomcat é, além de ser uma implmentação de referência das API's Servlets e JSP, prover uma implementação do conceito de 'Web Container'. Neste conceito uma das características fundamentais é permitir o acesso concorrente aos componentes que são executados dentro deste 'container'.
Contudo, a configuração 'default' do Tomcat traz um componente de Web Server que muitos chamam de 'Lightweight Web Server'. Este componente representa uma implementação simples e 'light' de um servidor http, mais para o propósito de desenvolvimento do que para produção. Para o ambiente de produção, o projeto Jakarta [1] (um dos projetos do grupo Apache [2]) recomenda o uso de um 'Apache Web Server' (ou qualquer outro Web Server) no lugar da implementação 'lightweight'. Assim, o 'Apache Web Server', uma sugestão óbvia do grupo Apache/Jakarta, se dedicaria em atender às requisições HTTP e prover as páginas e arquivos estáticos (que por sinal faz muito bem!), e quando estas requisições forem para componentes Web, este redirecionaria as requisições para o 'Web Container'. Daí o 'Web Container' deveria se dedicar em manter e executar os componentes Web (JSP/Servlets). Este mesmo cenário poderia prover o serviço de 'Load Balancing' e 'Fail-Over', onde poderiamos ter vários 'Web Servers' (Apache Web Server) atendendo às requisições HTTP e vários 'Web Containers' executando os componentes Web. Através deste cenário poderíamos obter performace melhores e daí atender cada vez mais usuários concorrentes.
Quanto às diferenças de acesso ao disco entre o Tomcat e o JBoss, suponho que a resposta esteja no fulano chamado 'Classloader' ([3] e [4]). Este indivíduo sempre causa confusão nas nossas cabeças quando estamos desenvolvendo ou implantando uma aplicação J2EE. As regras definidas nas especificações Servlet e J2EE para o 'Classloader' afeta deste uma simples aplicação Web (JSP/Servlets) até o escopo de acesso aos objetos nos componentes EJB [5]. Até empacotar as aplicações em arquivos .jar, .war, .rar e .ear muda consideravelmente com o 'Classloader' e quando desejamos ter acesso à outros arquivos, classes ou recuros contidos nestas aplicações e no servidor de aplicações [6], também. Por isso, entender como funciona o 'Classloader' no JRE ([7], [8] e [9]) e na arquitetura J2EE é fundamental e nos ajudará a evitar muita dor de cabeça.
Mas, o que o 'Classloader' tem a ver com o acesso à uma arquivo no disco? Tudo! Numa aplicação Web ou baseada em componentes EJB, que são executados num servidor de aplicações e num ambiente distribuído, recursos não 'serializáveis' podem ser usados mas não são recomendados. Dá trabalho ficar abrindo e fechando conexões com arquivos. Neste caso, não deveríamos, por exemplo, buscar um arquivo através da API de I/O (java.oi ou java.nio). Para acessar qualquer recurso devemos usar o 'Classloader' que, além de poder carregar classes [10], é capaz de localizar e carregar qualquer recurso que esteja no 'file System', num arquivo .jar, na rede via http, soap ou outros protocolos ou elementos distribuídos. As regras de 'Classloader' no 'EJB Container' se destacam mais e são mais rígidas do que no 'Web Container'. Por isso, pode parecer diferente entre o Tomcat e o JBoss, entre o 'Web Container' e o 'EJB Container'. Mas, o procedimento deveria ser o mesmo, já que a especificação J2EE é a mesma e é aplicada aos dois tipos de 'Containers' ([11] e [12]) .
Porém, existe uma pequena diferença entre o esquema de 'Classloader' na especificação 'Servlet' e o esquema geral da especificação 'J2EE' ([10] e [12]). No esquema 'Servlet' a hierarquia de 'Classloaders' primeiro procura as classes/arquivos no pacote da aplicação Web (WEB-INF/lib/**.jar e WEB-INF/classes) e depois delega a localização do recurso desejado para o 'Classloader' pai na hierarquia. Já no esquema J2EE, este obedece fielmente a especificação da Virtual Machine [10]. Ou seja, um 'Classloader', na hierarquia de 'Classloaders' primeiro sempre delega a localização para o seu 'Classloader' pai e somente quando este responde que não achou é que tenta-se localizar no próprio escopo. E se no escopo local não achar, o 'Classloader' responde para o seu 'Classloader' filho que não achou, se o escopo local não for o último da hierarquia. Portanto, no J2EE primeiro delega-se para o 'Classloader' pai, se este achar está resolvido, se não tenta achar localmente. Parece confuso, mas é necessário entender o esquema de 'Classloader' do Java para saber como ter acesso aos recursos no disco e como empacotar devidamente as aplicações Web ou EJB.
Segue no final deste e-mail uma lista de referências que pode ajudá-lo a esclarecer melhor toda esta confusão que armei ... Vale a pena desenbaraçar ...
Enjoy ... []´s
Spock
---------------------------------------------------------------------
[1]. The Jakarta Apache Project
http://jakarta.apache.org/
[2]. The Apache Software Foundation
http://www.apache.org/
[3]. java.lang.ClassLoader
http://java.sun.com/j2se/1.3/docs/api/java/lang/ClassLoader.html
[4]. The Basic of Java Class Loaders
http://www.javaworld.com/javaworld/jw-10-1996/jw-10-indepth_p.html
[5]. Advanced Classloaging in J2EE
http://www2.theserverside.com/resources/articles/AdvancedClassLoading/article.html
[6]. EJB 2 and J2EE Packaging
Part 1: http://www.onjava.com/pub/a/onjava/2001/06/26/ejb.html
Part 2: http://www.oreillynet.com/pub/a/onjava/2001/07/25/ejb.html
[7]. The Java Extension Mechanism
http://java.sun.com/j2se/1.3/docs/guide/extensions/index.html
[8]. Extension Mechanism Architecture
http://java.sun.com/j2se/1.3/docs/guide/extensions/spec.html
[9]. The Extension Mechanism Tutorial
http://java.sun.com/docs/books/tutorial/ext/
[10]. The Java Virtual Machine Specification.
Topic 5.3 Creation and Loading.
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#72007
[11] Tomcat Class Loader How-To
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html
[12]. JBoss 3.0 Administration and Development Documentation
http://www.jboss.org/docs/
---------------------------------------------------------------------
Glauco Cesar de Castro wrote:
>
Ola Spock.
Primeiramente, obrigado pelas dicas. Vou ver o que posso fazer.
Mas so respondendo a sua pergunta. Iniciamos o desenvolvimento com Tomcat. Isso a mais ou menos 3 anos. Ano
passado, quando colocamos o sistema em testes de performance, tivemos um
pequeno probleminha. Nao conseguiamos conectar mais que 3 usuarios
simultaneos (inclusive, na epoca, mandei alguns emails para a lista
pedindo socorro, o que resolveu algumas coisas). Achamos que poderia ser
o tomcat que nao estava dando conta do recado, pois havia lido que ele
nao e um servidor Web, e sim um "interpretador" JSP e que deveria
procurar um servidor Web (Apache por exemplo) e colocar o tomcat rodando
debaixo do mesmo. Como solucao, resolvemos utilizar o Jboss porque, alem
de parecer ser mais parrudo, iremos comecar a migrar o nosso sistema
para EJB.
Alem disso tudo, me corrija se estiver errado, existem algumas
peculiaridades quanto a programacao para o Jboss (JSP), principalmente
na parte de acesso a disco a partir do container Web. Entao, depois que
migramos para o Jboss, ficou complicado migrar de volta para o Tomcat.
Bom, em resumo e isso. Essa e a razao pela qual utilizamos o Jboss, e
nao apenas o tomcat, que sei resolveria meu problema.
Um abraco,
Glauco Cesar de Castro
-----Mensagem original-----
De: Dr. Spock [mailto:[EMAIL PROTECTED]] Enviada em: Monday, January 20, 2003 19:41
Para: [EMAIL PROTECTED]
Assunto: Re: [enterprise-list] Otimizacao do JBoss
Caro Glauco,
Se vc está utilizado somente JSP e algumas classes java, pq não só usar o Tomcat? Pq vc precisa do JBoss?
Se vc não estiver usando os recursos do JBoss e muito menos o 'EJB Container', acredito que vc não precise do JBoss. Basta uma distribuição
simples do Tomcat que vc pode obter em:
http://jakarta.apache.org/site/binindex.cgi
Fique atento para o fato de que existe uma distribuição do JBoss já integrado com o Tomcat. É possível que vc esteja usando essa distribuição. Então, se vc utiliza apenas o 'Web Container', não existe nenhum ganho significativo em usar o JBoss. Pq, no final das contas vc está apenas usando o Tomcat, mesmo no JBoss. Exceto, se vc estiver usando algum serviço especifico do JBoss que vc não encontraria somente no Tomcat. O mesmo acontece quando vc usa o JBoss integrado com o Jetty.
Então, pq não usar somente o Tomcat? Rubustez? Como disse, se vc não estiver usado algo que vc só encontra no JBoss, o JBoss, por sí só, não está agregando valor.
Mas, se realmente vc precisa do JBoss, vc poderá customizá-lo alterando ou removendo os arquivos de configurações dos serviços (services). Estes arquivos normalmente encontram-se em:
$JBOSS_HOME/server/default/deploy/
Procure pelos arquivos '*-service.xml'. Estes arquivos são usados pelo 'hot deploy' do JBoss para iniciar os serviços indicados nestes arquivos. Modificando-os ou removendo-os vc irá alterar a configuração dos serviços ativados no JBoss. Portanto, se vc desativar os serviços que são desnecessários no seu ambiente, vc poderá economizar memória.
Outros arquivos de configurações podem ser encontrados em:
$JBOSS_HOME/server/default/conf/
Cuidado para não desativar algum serviço essencial do servidor de aplicações.
Enjoy ... []´s
Spock
Glauco Cesar de Castro wrote:
Ola para todos.
Desenvolvi um sistema que, por enquanto, ainda nao esta usando EJB. Estou utilizando o Jboss (win2000 server) por ser free e por ser mais parrudo que o tomcat sozinho (que pro meu caso ja resolveria, pois estou utilizando JSP e classes JAVA). Bom, o problema eh que o servico
do Jboss esta consumindo 82 mega de memoria RAM no servidor. Minha pergunta é, como posso otimizar isso? Nao acho que seria necessario tudo isso de memoria apenas para interpretacao de paginas JSP e utilizacao de algumas classes JAVA.
Obrigado pela ajuda
Glauco Cesar de Castro
--------------------------------------------------------------------- Para cancelar a subscrição, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
