技術問題分析-超時02(10.25)
接昨天的分析。首先昨天分析了在600秒出現執行緒阻塞和掛起的時候，再等待了900秒出現連線超時，因此從時間上看是1500秒超時。為了印證這個假設，我們將Read Time out的時間修改為400秒，那麼就應該是1300秒報出服務超時的異常錯誤，但是最終測試的結果仍然是1500秒超時。
對於該超時，在OSB叢集側沒有任何5分鐘超時的設定，而檢查F5負載均衡的超時配置文件可以看到，F5負載均衡裝置上有一個idle time out的超時設定，預設就是300秒。因此為了解決該問題，首先還是要確定是否和負載均衡裝置有關係。
對於當前的服務呼叫，需要通過經過ESB服務叢集，業務系統的服務叢集，才能夠完成。如下：
即整個服務請求的呼叫過程是為1->2->3->4的順序，需要同時經過1和3兩個負載均衡裝置。那麼整個服務呼叫超時就和1,2,3,4四個節點的配置都會相關。因此為了進一步進行驗證，我們嘗試對如下路徑直接呼叫以排查問題。
1. 不走業務系統的負載均衡 1-2-4路徑呼叫
在該模式下通過管控系統和通過SOAPUI分別進行呼叫測試。發現整體呼叫能夠成功，有成功的例項返回。對於通過管控呼叫的時候會出現有重試的現象，但是通過SOAPUI呼叫的時候沒有發現重試。
其次對於客戶端呼叫仍然會出現5分鐘呼叫超時，返回Connection Reset的錯誤。但是這個時候實際上服務仍然還執行，即2-4的連線仍然在執行並能夠成功執行完，因此可以看到成功的服務執行例項資料。
2. 不走ESB和業務系統兩邊的叢集，走2-4直接進行介面服務呼叫。
在該模式下，我們通過SOAP/">SOAPUI對介面服務進行呼叫測試，能夠成功呼叫，有成功的例項返回，同時對於客戶端也可能得到成功的返回資訊。即既有成功的例項，客戶端也返回成功。即我們希望達到的一個結果。
3. 走兩邊的叢集模式 1-2-3-4路徑進行呼叫
這個即是最初的呼叫模式，我們還是使用SOAPUI進行呼叫，發現會出現呼叫重試，同時最終服務執行失敗，報1500秒的超時錯誤。在客戶端也會報出連線超時錯誤。即和我們最初看的現象是一致的。但是具體為何會發起5分鐘後的重試，以及是否該重試是由負載均衡裝置發起的暫時不明確。
在負載均衡上面，我們看到有tcp_tw_recycle引數配置，但是暫時不確定自動觸發重試是否和該引數的設定有關係，從網上文章來看是不建議對該引數配置進行啟用。
參考： ofollow,noindex">http://www.cnblogs.com/jdonson/p/4760080.html
該超時問題經過分析，基本確定是負載均衡的超時設定引起的，因此解決就簡單的，即對兩個叢集對應的負載均衡超時設定都進行調整，同時確保該超時時間>OSB服務配置中的Read Time out時間即可。