Caramba. Que aula. :) Bom, quanto as conexoes, ja foi resolvido. Quando peguei o projeto, ele ja estava um tanto quanto desenvolvido. Pra variar, as pessoas que haviam iniciado o projeto sairam da empresa e eu tive que continuar tocando tudo sozinho. O pior de tudo, conhecia e conheco muito pouco de java. Ja fiz um curso (ha uns 4 anos atraz) e nunca havia utilizado. Tive que aprender tudo na marra (o que ao meu ver e a melhor forma). Entao, voltando ao assunto das conexoes, depois de apanhar por mais ou menos 3 meses vasculhando o codigo e fazendo testes de performance com as ferramentas da Compuware (que são excelentes), descobrimos que o problema estava na persistencia. O pessoal que desenvolveu o sistema inicialmente achou uma implementacao de persistencia na internet parecida com EJB. Ele faz o mapeamento das classes e seus metodos no banco. Cada classe e metodo e mapeado para uma tabela. Bom, esse bacalhau todo que eles fizeram tava dando pau para car$#%(*#*. Se a gente colocava 5 usuarios simultanes (realmente simultaneos), o sistema se perdia. Dava problema de concorrencia, um iniciava uma operacao, o outro iniciava junto e quando esse acabava, o java nao conseguia acabar o outro. Bom, resolvi retirar a persistencia e criar outra. Fiz no "old fashion way". Criei uma classe persistente para cada classe de negocio que precisa ser persistente no meu sistema. Essa classe persistente tem todos os DMLs que necessito, escritos na mao, na forma mais otimizada possivel. Pode ser antiquado, mas funciona. Por esse e outros motivos, estaremos migrando para EJB.
Bom, acho que isso resume a estoria desse sistema. Tenho muito que fazer agora (uma lista de 12 links para ler). Mais uma vez obrigado pela ajuda, Glauco Cesar de Castro -----Mensagem original----- De: Dr. Spock [mailto:[EMAIL PROTECTED]] Enviada em: Tuesday, January 21, 2003 16:57 Para: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Assunto: Re: RES: [enterprise-list] Otimizacao do JBoss Olá Glauco, 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/ar ticle.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] --------------------------------------------------------------------- Para cancelar a subscrição, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
