Glassfish e IntersystemsCache, comportamento estranho[Resolvido]

Programação Java
#1

Olá Amigos GUJeiros.

Tenho algumas aplicações rodando num servidor Glassfish junto com um banco de dados Caché.
O problema que estou enfrentando é que em algumas situações isoladas e sem motivos aparente um pool de conexão fica preso e não volta mais, a não ser que eu mate o processo através do Painel de Adm do BD, no Glassfish acusa NumConnUsed 1, porém no Caché todas as conxões estão livres.

Procurando na internet encontrei alguns tutorais dizendo que isso facilmente poderia ser resolvido ativando a opção “Reclamação de perda” e preenchendo “Tempo-limite de perda” na configuração do Pool.
Só que essa mudança acabou causando um comportamento estranho no Glassfish, fazendo que quando acontecesse uma perda de conexão ele criasse inumeras conexões e por fim travasse, em algum momento ou outro ele até conseguia criar apenas uma conexão, mas em suma maioria ele ia criando até travar ou até atingir o tamanho máximo. Pensei que fosse algum problema entre a conversação do GF e do Caché e que esse monte de conexões era o GF tentando manter o numero minimo do tamanho do pool e que por algum motivo o BD estaria rejeitando a conexão.

Como geralmente acontecia em horarios de pico achei que este problema era devido uma perda de conexão justamente no momento em que todas as conexões permitidas do BD ja estavam sendo utilizadas(que é um relativamente comum aqui). Então o Glassfish criava uma conexão para manter o tamanho minimo de conexões, e o BD rejeitava esta conexão, então mais uma conexão era criada e consequentemente rejeitada e assim em diante, até travar.
Porém ontem de noite sem ninguem estar utilizando o servidor, com todas as conexões livros no BD, aconteceu isso de novo e minha teoria foi por agua a baixo.
No Log de erro acusa:

[#|2010-11-25T09:02:54.711-0200|WARNING|oracle-glassfish3.0.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource.pool|_ThreadID=74;_ThreadName=Thread-1;|A potential connection leak detected for connection pool PWGIDS. The stack trace of the thread is provided below : 
com.sun.enterprise.resource.pool.ConnectionPool.setResourceStateToBusy(ConnectionPool.java:319)
com.sun.enterprise.resource.pool.ConnectionPool.getResourceFromPool(ConnectionPool.java:694)
com.sun.enterprise.resource.pool.ConnectionPool.getUnenlistedResource(ConnectionPool.java:572)
com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(ConnectionPool.java:467)
com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:369)
com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:226)
com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:150
[#|2010-11-25T09:02:55.977-0200|WARNING|oracle-glassfish3.0.1|javax.enterprise.resource.resourceadapter.com.sun.gjc.spi|_ThreadID=54;_ThreadName=Thread-1;|RAR7115: Unable to set ClientInfo for connection
java.sql.SQLClientInfoException
	at com.intersys.jdbc.CacheConnection.setClientInfo(CacheConnection.java:1924)
	at com.sun.gjc.spi.jdbc40.ConnectionHolder40.setClientInfo(ConnectionHolder40.java:313)
	at com.sun.gjc.spi.jdbc40.ConnectionHolder40.close(ConnectionHolder40.java:521)
	at org.springframework.jdbc.datasource.DataSourceUtils.doReleaseConnection(DataSourceUtils.java:333)
	at org.springframework.jdbc.datasource.DataSourceUtils.releaseConnection(DataSourceUtils.java:294)
	at org.springframework.jdbc.datasource.DataSourceUtils$ConnectionSynchronization.beforeCompletion(DataSourceUtils.java:452)
	at org.springframework.transaction.support.TransactionSynchronizationUtils.triggerBeforeCompletion
[#|2010-11-25T09:39:12.706-0200|WARNING|oracle-glassfish3.0.1|javax.enterprise.resource.resourceadapter.com.sun.gjc.spi|_ThreadID=28;_ThreadName=Thread-1;|RAR5114 : Error allocating connection : [Error in allocating a connection. Cause: Connection could not be allocated because: [Cache JDBC] Communication link failure: Acesso Negado]|#]

Não sei se deu para entender, até que por ser um erro do qual eu nao sei bem o motivo fica meio complicado de explicar. Acredito que não seja algum erro de código das aplicações, pois utilizo jdbcTemplate e não crio nenhuma conexão na mão. Talvez alguma configuração do Glassfish que eu esteja deixando passar, ou algum bug no Driver do Caché talvez?

Alguém ja passou por algum problema semelhante ou tem alguma idéia do que possa ser? Qualquer ajuda é muito bem vinda!

#2

Esperança é a ultima que morre!

#3

Fiz um “debug” no driver do Caché, mais precisamente no método setClientInfo();

E antes de executar qualquer ação o método verifica o estádo da conexão e caso esteja fechada, lança um SQLInfoException; Que é o excpetion que esta sendo lançado no caso.
O que eu acho estranho é que mesmo ele caindo nessa condição como se estivesse fechada, a conexão com o banco de dados continua aberta, mas apenas esta ociosa pois no glassfish ela é interpretada como se estivesse em uso, e portanto não volta ao pool.

Então eu comentei esse if, e coloquei o driver jdbc para rodar sem ele, o que acontece agora é que a exceção não é mais lançada, a conexão com o banco de dados é fechada, porém o Glassfish continua acusando como se a conexão estivesse em uso.

Isto é ruim pois como ele interpreta que a conexão ainda existe, acaba não redimensionando o pool e ficando com uma conexao morta como se estivesse em uso.
Depois de muitas conexão perdidas serei obrigado a reniciar o glassfish para que ele renove as conexões.

Entrei em contato com o Suporte do Intersystems Caché, e me responderam que possivelmente é uma configuração mal feita do Spring/Hibernate, mas não faço a minima idéia do que possa ser, pois utilizo a mesma idéia de configuração com o MySql e SqlServer.

Alguém ja passo por algum problema semelhante ou tem alguma idéia do que possa ser?

#4

Apenas para deixar registrado aqui.

Depois de tanto procurar consegui resolver o maldito problema. Era um virus que de alguma maneira conseguia travar os processos. Ai quando o glassfish tentava fechar a conexão, não conseguia e dava leak.
Agora está fazendo cerca de 112h sem nenhum problema.

#5