前一陣子配合乙個isv一直在查訪問top服務鏈結被重置的問題，當時認為是sdk的問題，因此我就將sdk的資料鏈路層**單獨剝離出來給isv測試，沒有發現鏈結重置的問題。在加上部分業務**以後，有出現服務重置，但是概率很低。今天isv同學給我發來了修改後的**（重置情況降低），這種修改還是有道理的，因此後續配合會公升級sdk，這裡也分享一下。（當時也考慮過這方面的問題，但是看了實現**覺得概率不大，但是可能也就是這點概率在網路或者服務質量差的時候會被放大）
......
connection.getoutputstream().write(buffer.getbytes());
......
return response;
觀察 string body = fetchutil.inputstreamtostring(connection.getinputstream());的位置，其實在connection.getoutputstream().write(buffer.getbytes());這部已經將內容flush到服務端，此時由於沒有讀入輸入流，因此管道一直hold，做了很多和通訊不相關的事情，但是這期間的時間還是會被算入在通訊超時重置的時間內，因此將讀入資料流提前到發出請求以後，可以防止中間無關處理導致連線超時和鏈結重置的概率。這點在sdk中將改進，也提醒其他開發者，通訊流程中避免無關的處理嵌入在通訊事務中，降低通道利用率。對通訊通道的快取快放能夠增加處理能力，業務處理可以另起執行緒單獨後續處理。
這裡特別感謝挖財365_淘帳本，給出了這些**修改的反饋，希望更多的開發者可以從使用者加入到參與者來。
訪問TOP鏈結超時和重置問題
前一陣子配合乙個isv一直在查訪問top服務鏈結被重置的問題，當時認為是sdk的問題，因此我就將sdk的資料鏈路層 單獨剝離出來給isv測試，沒有發現鏈結重置的問題。在加上部分業務 以後，有出現服務重置，但是概率很低。今天isv同學給我發來了修改後的 重置情況降低 這種修改還是有道理的，因此後續配合...
memcache鏈結超時問題
spymemcache的timed out waiting for operation 問題 主要原因 在想memcache客戶端新增獲取資料時，主要spymemcache是基於nio非同步獲取的，所以當獲取資料時會把任務新增任務佇列等待執行 如圖1 同時spymemcache也會做資料獲取的鏈結超...
資料訪問超時問題的總結
我們經常會討論到資料訪問超時的問題，當資料庫伺服器在遠端，而且該操作需要耗用較長的時間的時侯，程式經常性出現一些超時的問題。那麼應該從幾個層面來 這個問題呢 1.首先，我們來了解一下sql server內部執行的時間 預設是無限期等待的，即無超時 2.其次，我們要知道sqlconnection的co...