kettle中JDBC Connection Reset问题分析

古城微笑少年丶 2022-04-15 02:53 602阅读 0赞

项目组测试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，都可以消除掉前述问题。根据资料介绍，这个变量用来控制客户端通过认证的时间间隔，假如认证时间超时，则本次数据库链接创建操作就会失败，而缩短超时时间，可以有效的阻止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

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/./urandom

现场实施人员对于这个帖子里的信息比较感兴趣。按照帖子里的修改方法，在测试环境和生产环境做了多次验证，惊喜的发现问题得到了解决。

即，在kettle中的spoop.sh文件中PENTAHO\_DI\_JAVA\_OPTIONS="-Xms1024m -Xmx2048m -XX:MaxPermSize=256m -Djava.security.egd=file:/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的介绍，比较详尽；  
参考地址：https://community.oracle.com/message/3701989