JDBC Connection Reset的問題分析

半年前開始，項目組測試MM在驗證功能時，經(jīng)常報怨講測試環(huán)境上的應用在啟動時很慢，偶爾會報失敗，遇到類似問題多數(shù)情況下重新啟動一次就可以啟動成功，但少數(shù)時候也有反復啟動不成功的案例。

當啟動失敗時，日志里有如下的異常，看起來似乎和網(wǎng)絡有關。

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)

應用使用的數(shù)據(jù)庫是Oracle，版本為11g R1和R2，Oracle和應用都運行在Linux環(huán)境，JDBC驅動是從Oracle官網(wǎng)下載的ojdbc6.jar。

由于這類問題出現(xiàn)的頻率比較低，出現(xiàn)問題的數(shù)據(jù)庫環(huán)境都被做過安全加固，加上我忙于其它事情，這個問題就被擱置起來，沒有去認真定位，測試MM的懷疑都被我以環(huán)境原因的理由搪塞過去。

最近兩個月，應用在多個生產(chǎn)環(huán)境部署時也出現(xiàn)了類似的現(xiàn)象，在有些生產(chǎn)環(huán)境，上述問題還會導致雙機切換不成功或者反復切換。做現(xiàn)場實施的同事對此抱怨很多，對我們的應用產(chǎn)生了懷疑。

看來這個問題需要認真對待，并且一定要解決了。

現(xiàn)象分析

從測試MM和現(xiàn)場實施人員的描述看，這個問題有以下幾個特征：

• 應用啟動時很慢，這時有很大概率會失?。?/li>
• 應用包括很多組件，其中大部分組件在啟動時都會嘗試訪問數(shù)據(jù)庫加載一些數(shù)據(jù)，而其中一個組件在訪問數(shù)據(jù)庫時經(jīng)常會報上述異常；
• 當啟動失敗時，檢查Oracle實例對應的alert日志時，發(fā)現(xiàn)出現(xiàn)有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環(huán)境都做過安全加固，而問題現(xiàn)象里有發(fā)現(xiàn)過TNS錯誤，所以剛開始定位問題的思路出了點偏差，一直以為和安全加固操作有關，所以尋找的資料也和Oracle相關。

根據(jù)網(wǎng)上的資料，在sqlnet.ora文件中定義SQLNET.INBOUND_CONNECT_TIMEOUT變量，經(jīng)過嘗試，設置為0或者一個比較大的值如30，都可以消除掉前述問題。根據(jù)資料介紹，這個變量用來控制客戶端通過認證的時間間隔，假如認證時間超時，則本次數(shù)據(jù)庫鏈接創(chuàng)建操作就會失敗，而縮短超時時間，可以有效的阻止DoS類型的攻擊。根據(jù)安全加固操作指導，加固操作確實包含用于修改認證超時時間的指令。

問題定位到這里，應該說找到了規(guī)避手段，也了解引發(fā)問題的初因，但現(xiàn)場實施人員對于我的解釋并不滿意。好在我又找到一條新線索。

新線索

從Oracle官網(wǎng)論壇里找到一個帖子，討論的問題和我遇到的問題類似，但提出的問題原因和解決方法比較有意思。按照帖子里的說法，問題的根因和Java的安全隨機數(shù)生成器的實現(xiàn)原理相關。

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

現(xiàn)場實施人員對于這個帖子里的信息比較感興趣。按照帖子里的修改方法，在測試環(huán)境和生產(chǎn)環(huán)境做了多次驗證，驚喜的發(fā)現(xiàn)問題得到了解決。

隨機數(shù)生成器

如果不是為了解決問題，平時也不會去刻意查閱底層實現(xiàn)相關的原理，這次是個好機會。網(wǎng)上關于/dev/random的介紹很多，只列出要點：

• /dev/random是Linux內(nèi)核提供的安全隨機數(shù)生成設備；
• /dev/random依賴系統(tǒng)中斷信息來生成隨機數(shù)，因而設備數(shù)目比較少時，產(chǎn)生隨機數(shù)的速度比較慢，當應用對隨機數(shù)的需求比較大時會供不應求；
• /dev/random在讀取時會阻塞調(diào)用線程；
• /dev/urandom是/dev/random的改良版本，解決了隨機數(shù)生成慢、阻塞調(diào)用的問題，但同時稍微降低了安全性；

Linux環(huán)境下man random命令可以查閱到/dev/random和/dev/urandom的介紹，比較詳盡；

參考資料

https://community.oracle.com/message/3701989

http://www.usn-it.de/index.php/2009/02/20/oracle-11g-jdbc-driver-hangs-blocked-by-devrandom-entropy-pool-empty

總結

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論