半年前開始，專案組測試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

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

現場實施人員對於這個帖子裡的資訊比較感興趣。按照帖子裡的修改方法，在測試環境和生產環境做了多次驗證，驚喜的發現問題得到了解決。

即，在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的改良版本，解決了隨機數生成慢、阻塞呼叫的問題，但同時稍微降低了安全性；