Servidor TOMCAT instável

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? :wink:

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? :wink:

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:

  1. Chamado um metodo do connection pool para devolver a mesma, como “AlgumConnectipnPool.releaseConnection(conn)”)

  2. 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: