Possuo um servidor TOMCAT, rodando uma aplicação em JSP , o fato é que tem horas que ele fica instável e para de responder… já expandi a capacidade do meu servidor para 512 MB RAM, tenho plena certeza que não é memória… alguém já passou por uma situação assim? Aguardo resposta… obrigado!!!
:shock: :shock:
Pode ser um problema com sua conexao com o BD.
Vc usa pool de conexoes?
Olá fcanjos, já ouvi falar… mas não tenho o conceito correto sobre isso… gostaria que me desse maiores esclarecimentos sobre isso… ou como implementar um … esta é uma aplicação que está rodando na empresa e não pode parar e está me dando muita dor de kbça… obrigado pela força desde de já !!! Só para o seu conhecimento técnico estou usando FIREBIRD e TOMCAT 50.0.25…
Bom,
A coisa funciona mais ou menos assim:
Vc tem uma coleção de conexões que ficam sempre ativas com o seu banco.
Toda vez que vc precisar fazer uma conexao, ao inves de ter que abri-la e depois fecha-la qdo nao estiver mais usando, pega uma conexao emprestada do pool de conexoes, faz o que tem que fazer e depois devolve. Isto elimina o overhead da abertura e fechamento de conexoes toda vez que vc precisa acessar o banco.
O problema é que se vc esquece de devolver a conexao, ela permanece alocada, consumindo recursos do seu sistema. E quando nao houver mais conexões livres, vc acabara recebendo um time out.
O primeiro passo é descobrir se este é o problema em questao. Dê uma olhada no log do tomcat ($CATALINA_HOME/logs/catalina.log) quando o problema estiver ocorrendo.
Se vc tiver sorte, vai encontrar alguma pista lá!!
Até mais!!
so completando,
mesmo conexões que vc pega do pool vc SEMPRE deve fecha-la explicitamente com close(), de preferencia no finnaly, p/ garantir que vai ser feito.
feito isso ela vai ser devolvida para o pool.
[]'s
[quote=jgbt]so completando,
mesmo conexões que vc pega do pool vc SEMPRE deve fecha-la explicitamente com close(), de preferencia no finnaly, p/ garantir que vai ser feito.
feito isso ela vai ser devolvida para o pool.
[]'s
[/quote]
Nao necessariamente. Isso vai depender do teu pool. Ha pools onde vc chama do close() dele, mas por tras dos panos esta rolando uma interceptacao, e a conexao “fisica” eh mantida aberta ainda. Do que adiantaria um pool se vc da close na connection toda vez? 
Muitos sistemas implementam um wrapper para java.sql.Connection, onde o metodo close() eh sobrescrito para lidar com a situacao. Ai, mesmo que vc chame o close() da connection diretamente, o que vai acontecer eh algo um pouco diferente.
Rafael
[quote=Rafael Steil][quote=jgbt]so completando,
mesmo conexões que vc pega do pool vc SEMPRE deve fecha-la explicitamente com close(), de preferencia no finnaly, p/ garantir que vai ser feito.
feito isso ela vai ser devolvida para o pool.
[]'s
[/quote]
Nao necessariamente. Isso vai depender do teu pool. Ha pools onde vc chama do close() dele, mas por tras dos panos esta rolando uma interceptacao, e a conexao “fisica” eh mantida aberta ainda. Do que adiantaria um pool se vc da close na connection toda vez?
Muitos sistemas implementam um wrapper para java.sql.Connection, onde o metodo close() eh sobrescrito para lidar com a situacao. Ai, mesmo que vc chame o close() da connection diretamente, o que vai acontecer eh algo um pouco diferente.
Rafael[/quote]
bom, no caso do jboss ele fecha a conexão, mas da um warning bem claro, tipo: “closing connection for you, please close yourself”, por isso acho uma boa pratica sempre fechar a conexão.
e com isso vc libera a conexão p/ o pool novamente, isso claro se vc ja terminou a transação.
[]'s
Entao, mas veja bem: “closing connection for you” nao significa necessariamen que o link “real” ao banco esta sendo fechado. O servidor apenas esta te alertando de algo que vc deveria ter feito. Nao sei como funciona no JBoss, mas eh preciso ter em mente que o getConnection() que vc da do connection pool pode ser uma implementacao de java.sql.Connection especial para lidar com a situacao.
Rafael
eu realmente não sei como funciona internamente, então fica dificil de eu argumentar.
mas Rafael, se eu não fechar a connection, quando ela voltara para o pool?? por time out?? ou quando a transação for terminada???
[]'s
Tem duas maneiras comuns de retornar a conexao ao pool:
-
Chamado um metodo do connection pool para devolver a mesma, como “AlgumConnectipnPool.releaseConnection(conn)”)
-
chamado o metodo close() de uma implementacao de java.sql.Connection.
No caso da opcao 2, o metodo close() nao vai liberar a fechar a conexao de fato (perdendo o link com o servidor), mas sim fazer por vc o trabalho de retornar a mesma ao pool.
Em outras palavras, as conexoes de um pool estao sempre abertas com o servidor de banco de dados, e eh por isso que existem as opcoes de “pingar” as mesmas antes de retornar, ou executar alguma query para ver se a mesma eh valida, e assim por diante.
Alguns bancos de dados, como o mysql e o Oracle, tem um limite de timeout (no mysql sao 8 horas, no oracle nao lembro), sendo entao necessario que elas sejam testas antes de serem liberadas para o uso. (claro os testes costumam ser opcionais e desabilitados por padrao em mtos casos)
Rafael
blz, era como eu imaginava, so que eu achava que elas eram fechadas, mas na verdade são so liberadas.
vlw!!
[]'s
Depois de uma luta quase q interminável, descobri o que estava impossibilitando a resposta do web container “Apache TOMCAT” - Estava com uma versão 1.01 do Firebird e verifiquei seu log de erro q estava me reportando uma coisa do tipo “INET ERROR” , converti minha base para o Firebird 1.05 Super Server e aplicação voou… não tinha nada haver com o TOMCAT … na verdade ele sempre trabalhou bem… :idea: :lol: