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]
