We are having some issues with an application of ours which we are attempting to diagnose. While taking a close look at things, we think we may be having some DBCP connection pool issues.
Among a few things we noticed, we discovered something via a secondary support application (small JDBC based sqlclient for monitoring the DB) using the same driver the main application uses. That discovery was entropy exhaustion. After applying the fix noted in Oracle JDBC intermittent Connection Issue to this small utility, the issue went away.
At that time, we suspected the main application could be suffering from the same problem. We did not apply the same fix at this point, but rather we've started monitoring available entropy via /proc/sys/kernel/random/entropy_avail every 5 seconds to validate.
After reviewing the data for a 24 hour period, we do not see the same drop in available entropy as with the jdbc utility prior to the use of /dev/urandom. Rather, we noticed that the entropy never drops below 128 bytes nor climbs above 191 bytes. We have searched the application configuration files and can't find anything related to specifying the random number source.
OS: Red Hat Enterprise Linux Server release 6.3 (Santiago)
JDBC Driver: ojdbc6-11.2.0.3
Pooling Method: Hibernate DBCP
So, my questions are:
1) If we've not knowingly told the application/driver to use /dev/urandom vs /dev/random, what would possibly explain why we don't see the same entropy drop when new pool connections are created?
2) Why would the minimum and maximum available entropy be so rigid at 128/191? I would expect a little more, pardon the pun, randomness in these values.
I hesitate to go posting a bunch of configuration files not knowing which may be relevant. If there is something particular you'd like to see, please let me know and I will share.
