Oracle 11g JDBC driver blocked by /dev/random

This time I was promoting my new application to the Testers env. Everything was working on quite good, deployments were made with our CD tool, everything automated and had deployed the application several times in dev env. Everything was happiness until I crashed into a wall because I couldn't connect to the database ¬¬. I'm not going to make this history longer but the main problem has to do with the secure random numbers the oracle driver uses to login. This random number generation is delegated to the OS, in this case Unix. In my very particular case the problem had to do with the configuration of the server where I deployed my application.

It was only after printing out the stack trace of my application that it was hung because the oracle driver was waiting for a secure random number being generated:


Thread[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2,5,main]
      java.io.FileInputStream.readBytes(Native Method)
      java.io.FileInputStream.read(FileInputStream.java:255)
      sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedBytes(SeedGenerator.java:539)
      sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144)
      sun.security.provider.SecureRandom$SeederHolder.(SecureRandom.java:203)
      sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:221)
      java.security.SecureRandom.nextBytes(SecureRandom.java:468)
      oracle.security.o5logon.O5Logon.a(Unknown Source)
      oracle.security.o5logon.O5Logon.(Unknown Source)
      oracle.jdbc.driver.T4CTTIoauthenticate.(T4CTTIoauthenticate.java:582)
      oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:401)
      oracle.jdbc.driver.PhysicalConnection.(PhysicalConnection.java:553)
      oracle.jdbc.driver.T4CConnection.(T4CConnection.java:254)
      oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32)
      oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:528)
      com.mchange.v2.c3p0.DriverManagerDataSource.getConnection(DriverManagerDataSource.java:134)
      com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:182)
      com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:171)
      com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.acquireResource(C3P0PooledConnectionPool.java:137)
      com.mchange.v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java:1014)
      com.mchange.v2.resourcepool.BasicResourcePool.access$800(BasicResourcePool.java:32)
      com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1810)
      com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)

java.security.SecureRandom was waiting for some bytes, strange. I googled. Then I had to learn and understand a bit about entropy noise and could realize, with a little help from my Unix friends, that one of the servers had no installed a package that generates the "noise".

As mentioned in the following post I ran the next commands:
cat /proc/sys/kernel/random/entropy_avail
23
cat /proc/sys/kernel/random/poolsize
4096

So there where too few entropy available to generate a secure random number.

After installing the package
cat /proc/sys/kernel/random/entropy_avail
4096
Afterwards I had no more apparent deadlocks, my application could get connections to the DB.