2014年7月13日
半年前開始。项目组測试MM在验证功能时。常常报怨讲測试环境上的应用在启动时非常慢，偶尔会报失败，遇到类似问题多数情况下又一次启动一次就能够启动成功，但少数时候也有重复启动不成功的案例。当启动失败时。日志里有例如以下的异常。看起来似乎和网络有关。
|
java.sql.SQLRecoverableException: I/O Exception: Connection reset at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:281) at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:118) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:224) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:296) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:611) at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:455) at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:494) at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:199) at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:30) at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:503) at java.sql.DriverManager.getConnection(DriverManager.java:582) at java.sql.DriverManager.getConnection(DriverManager.java:154) |
应用使用的数据库是Oracle，版本号为11g R1和R2，Oracle和应用都执行在Linux环境，JDBC驱动是从Oracle官网下载的ojdbc6.jar。
因为这类问题出现的频率比較低，出现故障的数据库环境都被做过安全加固。加上我忙于其他事情。这个问题就被搁置起来。没有去认真定位，測试MM的怀疑都被我以环境原因的理由搪塞过去。
近期两个月。应用在多个生产环境部署时也出现了类似的现象。在有些生产环境，上述问题还会导致双机切换不成功或者重复切换。
做现场实施的同事对此抱怨非常多，对我们的应用产生了怀疑。看来这个问题须要认真对待，而且一定要攻克了。
现象分析
从測试MM和现场实施人员的描写叙述看，这个问题有下面几个特征：
1) 应用启动时非常慢，这时有非常大概率会失败；
2) 应用包含非常多组件，当中大部分组件在启动时都会尝试訪问数据库载入一些数据，而当中一个组件在訪问数据库时常常会报上述异常。
3) 当启动失败时，检查Oracle实例相应的alert日志时，发现出现有TNS错误，样比例如以下：
|
Fatal NI connect error 12170. VERSION INFORMATION: TNS for Linux: Version 11.2.0.1.0 - Production Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.1.0 - Production TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.1.0 - Production Time: 11-MAY-2014 22:23:40 Tracing not turned on. Tns error struct: ns main err code: 12535
TNS-12535: TNS:operation timed out ns secondary err code: 12560 nt main err code: 505
TNS-00505: Operation timed out nt secondary err code: 110 nt OS err code: 0 |
问题定位
TNS错误
因为实验室里的Oracle环境都做过安全加固，而问题现象里有发现过TNS错误，所以刚開始定位问题的思路出了点偏差，一直以为和安全加固操作有关。所以寻找的资料也和Oracle相关。
依据网上的资料。在sqlnet.ora文件里定义SQLNET.INBOUND_CONNECT_TIMEOUT变量。经过尝试。设置为0或者一个比較大的值如30，都能够消除掉前述问题。
依据资料介绍，这个变量用来控制client通过认证的时间间隔，假如认证时间超时，则本次数据库链接创建操作就会失败，而缩短超时时间。能够有效的阻止DoS类型的攻击。
依据安全加固操作指导，加固操作确实包括用于改动认证超时时间的指令。
问题定位到这里，应该说找到了规避手段，也了解引发问题的初因。但现场实施人员对于我的解释并不惬意。好在我又找到一条新线索。
新线索
从Oracle官网论坛里找到一个帖子。讨论的问题和我遇到的问题类似，但提出的问题原因和解决方法比較有意思。依照帖子里的说法，问题的根因和Java的安全随机数生成器的实现原理相关。
|
java.security.SecureRandom is a standard API provided by sun. Among various methods offered by this class void nextBytes(byte[]) is one. This method is used for generating random bytes. Oracle 11g JDBC drivers use this API to generate random number during login. Users using Linux have been encountering SQLException("Io exception: Connection reset"). The problem is two fold 1. The JVM tries to list all the files in the /tmp (or alternate tmp directory set by -Djava.io.tmpdir) when SecureRandom.nextBytes(byte[]) is invoked. If the number of files is large the method takes a long time to respond and hence cause the server to timeout 2. The method void nextBytes(byte[]) uses /dev/random on Linux and on some machines which lack the random number generating hardware the operation slows down to the extent of bringing the whole login process to a halt. Ultimately the the user encounters SQLException("Io exception: Connection reset") Users upgrading to 11g can encounter this issue if the underlying OS is Linux which is running on a faulty hardware. Cause The cause of this has not yet been determined exactly. It could either be a problem in your hardware or the fact that for some reason the software cannot read from /dev/random Solution Change the setup for your application, so you add the next parameter to the java command: -Djava.security.egd=file:/dev/../dev/urandom |
现场实施人员对于这个帖子里的信息比較感兴趣。依照帖子里的改动方法，在測试环境和生产环境做了多次验证，惊喜的发现问题得到了解决。
随机数生成器
假设不是为了解决这个问题，平时也不会去刻意查阅底层实现相关的原理，这次是个好机会。网上关于/dev/random的介绍非常多。仅仅列出要点：
1) /dev/random是Linux内核提供的安全随机数生成设备；
2) /dev/random依赖系统中断信息来生成随机数，因而设备数目比較少时，产生随机数的速度比較慢，当应用对随机数的需求比較大时会供不应求。
3) /dev/random在读取时会堵塞调用线程。
4) /dev/urandom是/dev/random的改良版本号。攻克了随机数生成慢、堵塞调用的问题，但同一时候略微减少了安全性；
5) Linux环境下man random命令能够查阅到/dev/random和/dev/urandom的介绍，比較详尽。