問題現象

晚上版本上線后，發現工號進入首頁后頁面空白，顯示INTERNAL_SERVER_ERROR

過程回顧

• 通過fiddler抓包，發現某個請求出現500錯誤
• 檢查應用，was，ihs日志,沒有發現有效日志
• 發現只有部分工號有問題，開始懷疑存在數據問題，準備導數據回測試環境驗證
• 同時，新建一套ihs和was環境進行驗證
• 新環境驗證，發現原來失敗的工號可以正常，懷疑環境配置有問題。同時發現請求超過4s就會返回500錯誤
• 嘗試直接訪問原was,發現是正常的
• 對比兩個環境配置，was和ihs配置是一樣的，但plugins-in參數ServerIOTimeout有差異，舊的是-1,新的為0
• 修改新的為-1,訪問問題重現
• 準備修改為0，問題修復

技術分析

關于ServerIOTimeout參數的描述，以及取值為負數的情況，描述如下:

ServerIOTimeout value can be either positive or negative. If positive, when the ServerIOTimeout pops, the plug-in will not mark that server down. If negative, when the ServerIOTimeout pops, it will mark that server down. If your application uses HttpSession object, then there will be session affinity in play, so it would be best to choose a negative ServerIOTimeout value, to ensure that the retry will not be sent back to the same server that just timed-out. Since that server will be marked down, the retry will go to a different appserver in the cluster.

簡單來說，關于參數的取值都是需要權衡的。ServerIOTimeout表示ihs和was之間連接的讀寫超時時間，取值有三種值:

• 0 表示一直等待was響應，這樣可能會造成長時間不響應，連接也不釋放
• 正數 表示讀寫超時時間，超時之后會重試，這樣可能會造成業務重復受理
• 負數 和正數一樣，不過超時之后會認為當前was為下線狀態，然后重試其他服務器，對于無狀態的請求同樣可能有重復受理的問題。在上面的問題中，ihs后面有4個was，所以剛好看上去就是超過4s會超時

小總結

• 優化應用日志很重要，特別是那些沒什么用的異常日志，需要定期優化現網日志
• 最小化的可重現問題的環境
• 熟悉常見調試工具，如fiddler,telnet,wget,curl,tcpdump等
• 修改參數應該慎重，知道參數的含義，不要想當然。這次就是以為-1和0是沒有區別

這個文章也是3年前的，整理分享。

總結

以上是生活随笔為你收集整理的qt连接错误ip的sqlserver超时时间_参数设置导致请求超时案例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。