我们正在尝试诊断我们的应用程序存在一些问题。在仔细研究事物的同时，我们认为可能会遇到一些DBCP连接池问题。
在我们注意到的一些事情中，我们使用主应用程序使用的相同驱动程序通过辅助支持应用程序（基于JDBC的小型sqlclient监控数据库）发现了一些内容。那个发现是熵疲惫。将Oracle JDBC intermittent Connection Issue中提到的修复程序应用于此小型实用程序后，问题就消失了。
当时，我们怀疑主要应用程序可能遇到同样的问题。我们此时没有应用相同的修复，而是我们每隔5秒就开始通过/ proc / sys / kernel / random / entropy_avail监视可用的熵来进行验证。
在查看数据24小时后，我们看不到与使用/ dev / urandom之前的jdbc实用程序相同的可用熵下降。相反，我们注意到熵永远不会低于128字节，也不会超过191字节。我们搜索了应用程序配置文件，找不到与指定随机数源相关的任何内容。
OS: Red Hat Enterprise Linux Server release 6.3 (Santiago)
JDBC Driver: ojdbc6-11.2.0.3
Pooling Method: Hibernate DBCP
所以，我的问题是：
1）如果我们没有故意告诉应用程序/驱动程序使用/ dev / urandom vs / dev / random，那么什么可能解释为什么我们在创建新池连接时看不到相同的熵丢失？
2）为什么最小和最大可用熵在128/191处如此僵硬？我会期待更多，原谅双关语，这些价值观的随机性。
我不愿意发布一堆配置文件，不知道哪些配置文件可能是相关的。如果有什么特别的东西你想看，请告诉我，我会分享。
答案 0 :(得分：0)
您的应用程序是否使用JDBC连接池，或者它是否像您的测试应用程序那样经常进行身份验证尝试？ 请记住，每次身份验证尝试都会使用随机池。