訪問TOP鏈結超時和重置問題

2021-08-25 06:26:51 字數 761 閱讀 4433

前一陣子配合乙個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...