Unable to get a connection pool of a PoolingDataSource

[kxen42]

We are occasionally encountering a problem where we can't get a connection from the pool after the network connection was dropped and recovered.
java.sql.SQLException: unable to get a connection from pool of a PoolingDataSource containing an XAPool of resource feebase with 0 connection(s) (0 still available)
at bitronix.tm.resource.jdbc.PoolingDataSource.getConnection(PoolingDataSource.java:262)
...
Caused by: java.sql.SQLException: unable to connect to non-XA resource oracle.jdbc.OracleDriver
....
Caused by: java.sql.SQLRecoverableException: IO Error: Connection reset
....
Caused by: java.net.SocketException: Connection reset

What can we do to 'reboot' PoolingDataSource, or is there a configuration we should set to get it to auto-recover?

We are using btm 2.1.1, and I have found a similar problem reported for btm 2.1.4 on StackOverflow similar problem reported for 2.1.4 so I'm not confident that upgrading versions will fix the problem.
We are running on a linux server, and we're using Spring 3.1.2.

[lorban]

Did you enable some form of connection testing on your pool, like enableJdbc4ConnectionTest or testQuery?

[kxen42]

Yes we do. It is selecting the sysdate from dual.

I just cloned the source code today, and searched for the lines in the stacktrace, and it looks like we are actually using the btm-2.1.3.jar. Also, we are using com.oracle:ojdbc7:12.1.0.2.0.

We are able to run the application a couple times, each time it takes longer to run, and then it fails.

I have attached a log for a working instance, and a failing instance.

works.txt
fails.txt

[kxen42]

We found the cause and solution for our problem. I don't know if there is anything Bitronix could do about it.
We are using encrypted passwords on a linux box, and the oracle driver was having a problem. The clue to the problem is at the very end of the stacktrace. The StackOverflow item Oracle JDBC Intermittent Connection Issue explains what we ran into. Adding -Djava.security.edg=file:///dev/urandom fixed the problem.
exception.txt[exception.txt]

[emoreno619]

Is this issue similar to the issue described here?

If not, how do they differ? Also, in the linked issue, the stack trace he provides is much longer and more informative than mine. I only see the top most layer of the stack trace. How can I see a more verbose version?