Sql Server的JDBC連接重置錯誤：只有在Amazon EC2上

背景：雲Sql Server的JDBC連接重置錯誤：只有在Amazon EC2上

我們有一個基於Java的Web應用程序，我們在我們自己的服務器託管正常。最近我們使用Amazon Web Services（AWS EC2）雲來託管一個實例。

此「雲端設置」符合我們典型的「現場」設置：應用服務器的一臺服務器，數據庫服務器的另一臺服務器。（幾個應用服務器指向同一數據庫服務器）

在這種雲設置中，我們接收間歇「連接重置由對等的錯誤」的數據庫，並且JDBC驅動，其中，在（貌似）隨機時間間隔之間的問題並且在代碼庫中的隨機點上，數據庫連接失敗。

以下是日誌幾個錯誤摘錄

堆棧跟蹤實施例1：

at com.participate.pe.genericdisplay.client.taglib.GenDisplayViewTag.doStartTag(GenDisplayViewTag.java:77) 
    ... 75 more 
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The connection is closed. 
    at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:170) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.checkClosed(SQLServerConnection.java:304) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.getMetaData(SQLServerConnection.java:1734) 
    at org.jboss.resource.adapter.jdbc.WrappedConnection.getMetaData(WrappedConnection.java:354)

堆棧跟蹤實施例2

at java.lang.Thread.run(Thread.java:619) 
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1368) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1355) 
    at com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:1532) 
    at com.microsoft.sqlserver.jdbc.TDSReader.readPacket(IOBuffer.java:3274) 
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4437) 
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4389) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection$1ConnectionCommand.doExecute(SQLServerConnection.java:1457) 
    at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4026) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1416) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectionCommand(SQLServerConnection.java:1462) 
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.setAutoCommit(SQLServerConnection.java:1610) 
    at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkTransaction(BaseWrapperManagedConnection.java:429)

技術環境

的Jboss 4.2.2.GA（JBoss的Web 2.0的/ Tomcat的6）
MSSQL 2005年2.0 JDBC驅動程序

幾點

我們有從未見過這個問題在我們自己的環境（即自己的數據中心）運行該應用程序幾年
這導致我總結「有趣的事情正在與亞馬遜網絡環境進行」。我可能是錯的/錯過了某些東西/等等。
這個問題只發生在我們的應用程序中。我們有其他的Java和PHP應用程序沒有這個問題。其他Java應用程序使用不同的JDBC驅動程序（JTDS，據我所知）
它似乎並不像一個簡單的連接超時

問題

都具有一個沒有人見過這個？ - 如果這是一個EC2「已知問題」，我們可以配置我們的方式解決問題（即確保一切都在自己的子網或虛擬私有云（vpc）？ - 任何jdbc驅動程序設置來解決這個問題？

** **更新我延伸過關於這個問題增加了賞金

在信息額外位：兩個虛擬服務器（數據庫和應用服務器）爲不同的子網 - 即一個跳。兩臺服務器之間。

在非雲環境中，我們有兩個服務器「零跳」。

我們的託管管理員表示我們無法控制我們的EC2實例的子網。這讓我懷疑虛擬私有云是否會有所幫助。提前

感謝

將

來源

2011-06-03 user331465

您是否嘗試將JDBC驅動程序切換至jTDS？應該是一個簡單的嘗試。 – MicSim 2011-06-06 20:37:25

驅動程序更改將需要完整的qa週期。從理論上講，所有jdbc驅動程序的工作原理都是一樣的（即「理論上的共產主義有效」）......實際上，它們有輕微的變化......所以在這一點上它不適合我們。 – user331465 2011-06-06 20:52:32

您是否在應用程序中的多個線程之間共享連接？或者是否有像防火牆這樣的網絡元件在預設的時間量後斷開連接（恐怕我對EC2不瞭解）？第二個堆棧跟蹤是從通道讀取時遇到IOException的結果。由於基礎邏輯連接（SQLServerConnection實例）本身先前已關閉，因此異常本身處理不正確。這表明邏輯連接是共享的，或者底層物理連接被中斷。 – 2011-06-11 15:01:10

對於使用DBCP /連接池功能來緩解問題，只需謹慎一點 - 您啓用'testOnBorrow'和其他功能的次數越多，就越能夠引入延遲或其他性能變化對系統的影響。我不知道DBCP是否仍然這樣做，但幾年前它會生成實際的測試查詢來測試連接 - 完整堆棧，數據庫響應 - 而不僅僅是在網絡層。來自Brian的上述鏈接從2000年代早期就帶來了關於JDBC連接管理的重新嘗試邏輯的可怕回憶。

不管怎麼說，這是很難真正根源導致此，除了收集證據，並消除「看似隨意的」一組特定的條件：

你可以試着扔了一個Wireshark的/ PCAP跟蹤，發現當它發生，並將結果發送到亞馬遜和微軟，看看他們是否能根本原因是
你可以試試上面的某些測試工具來隔離問題（JMeter的測試，以獲得併發了），反彈網絡連接，注意恢復等。
您可以嘗試替代版本的SQL Server來折扣已修復的SQL Server/JDBC驅動程序錯誤。
如果DNS在連接字符串中使用，可以使用IP地址來驗證NSLOOKUP問題

我不是一個SQL Server的專家，但對研究其他途徑可能是相關產品領域內 - 例如看看是否有人遇到與TFS/Sharepoint類似的問題（例如http://nickhoggard.wordpress.com/2009/12/07/further-experiences-with-tfs-2010-beta-2-on-amazon-ec2/）

來源

2011-06-20 02:05:07

不知道這是否是相關或不相關。我們遇到了與我們在EC2環境中運行的應用類似的東西。同樣的症狀，數據庫連接會間歇性關閉。我們正在使用MSSQL 1.2驅動程序。另外，我們會在連接延遲或空閒時間後看到錯誤。我們的假設（從未證明）是網絡層的某些事情正在關閉連接，客戶端沒有檢測到它，所以它變得陳舊了。

我們能夠解決這個問題，因爲我們使用的是公共連接池，並讓池在失敗時重新創建連接。我們最終將應用程序從EC2中移出，但沒有再看到問題。

來源

2011-06-13 17:12:53

嗨，這是迄今爲止最有幫助的答案 - 我確認有人看到類似的問題，但我真的對「根本原因」感興趣..所以我擴展並增加了賞金 – user331465 2011-06-14 16:35:12

我在EC2環境和Windows Azure環境中都看到過這個問題。在分佈式計算環境中工作時，我認爲連接重試邏輯需要成爲您設計的標準部分。

This article適用於SQL Azure - 但我認爲它同樣適用於EC2和所有驅動程序。

來源

2011-06-13 17:34:52

我也可以確認發生了這種情況，並且由於它不是生產關鍵，所以會啓動一個較低優先級的調查。
我們的生產服務器位於我們的數據中心。我們使用開發人員手提電腦運行我們的應用程序。一旦我們配置了c3p0連接池超時和測試周期，這些問題都不會發生（請參閱文章：http://www.codefin.net/2007/05/hibernate-and-mysql-connection-timeouts.html）。

但是，我們確實有一個EC2中的開發登臺服務器，它確實發生在那裏。如果我發現似乎有用的東西，我會回來。另外，我正在使用mysql。我看到您正在使用MS SQL Server，因此它是跨數據庫供應商的。

來源

2012-02-02 13:40:12

Sql Server的JDBC連接重置錯誤：只有在Amazon EC2上

回答

相關問題