2009-08-07 156 views
5

我們的客戶之一有一個新問題:應用程序停頓。線程轉儲顯示所有線程掛在JDBC調用中的網絡IO上。JDBC連接掛起

我們從未見過這些'網絡IO'掛起。通常情況下,帶有數據庫問題的慢機器具有a)一個或兩個長時間運行的查詢或b)某種類型的鎖定/死鎖。在這兩種情況下,線程都會掛在不同的方法上。我從來沒有看到網絡IO上掛着所有30多個線程。

下面我已經包含了線程轉儲的摘錄。所有HTTP線程掛在同一個java.net.SocketInputStream.read呼叫。

我跟他們的dba和sysadmin聊過。根據他們最近在環境中「沒有任何變化」會導致這個問題。

分貝的環境

MSSQL 2005 64位Service Pack 2的 驅動程序:sqljdbc.jar:1.0 809 102

注:它們運行的​​是較舊的JDBC驅動程序。 AFAIK他們試圖從1.0升級到1.2的驅動程序,但還有其他一些問題。

他們正在同時運行的應用程序服務器和VMware虛擬機的數據庫服務器

其他環境問題。我不知道這個設置如何影響網絡性能。

顯然這是這個問題的唯一應用。我不知道他們的網絡架構。

問題 *有關此問題的任何見解? *如果是網絡,下一步是否需要分析?

附錄A:從線程轉儲摘錄

所有的HTTP連接都掛在同一個方法:

 
"TP-Processor31" daemon prio=5 tid=0x04085b78 nid=0x970 runnable [0x0764d000..0x0764fd6c] 
    at java.net.SocketInputStream.socketRead0(Native Method) 
    at java.net.SocketInputStream.read(SocketInputStream.java:129) 
    at com.microsoft.sqlserver.jdbc.DBComms.receive(Unknown Source) 
    at com.microsoft.sqlserver.jdbc.IOBuffer.sendCommand(Unknown Source) 
    - locked (a com.microsoft.sqlserver.jdbc.DBComms) 
    at com.microsoft.sqlserver.jdbc.SQLServerStatement.sendExecute(Unknown Source) 
    at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteQuery(Unknown Source) 
+0

如果連接通過一個愚蠢的NAT網關 – nos 2009-08-07 21:26:40

回答

8

我們已經有類似的問題,並跟蹤他們回到馬車JDK更新(29年6月1日)。

我們下載了1.6.27(http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase6-419409.html#jdk-6u27-oth-JPR),re - 設置JAVA_HOME環境,我們回到了正軌。

+2

我見過類似的東西非常感謝您的確切答案。我們有完全相同的問題,我們將其追蹤到在Glassfish中ping通JDBC連接池,該連接池掛起時沒有任何錯誤消息。恢復到1.6.27解決問題。謝謝 – 2011-11-21 11:42:21

+0

我們遇到了同樣的問題。降級會解決它。 – 2012-01-16 15:32:26

2

這是對版本1.6 u29中JSSE的更改。變化是部分補丁CVE-2011-3389CVE-2011-3560

如果不部署applet並使用java web-start。您可能只能使用1.6 u27 jsse.jar。你仍然會有這個漏洞,但它會允許sqljdbc.jar和sqljdbc4.jar工作。

遷移到Java 7的其他選項sqljdbc4.jar在該環境中工作。

該修補程序不完整修復。所以希望未來的補丁有更多的變化。