自從SEOTcs系統(tǒng)11月份24日更新了一下SEO得分算法以來，一直困擾我的一個問題出現(xiàn)了，java的數(shù)據(jù)job任務，在執(zhí)行過程中會經(jīng)常報以下的錯誤：

“2011-12-03 18:00:32 DefaultHttpClient [INFO] I/O exception (java.net.SocketException) caught when processing request: Connection reset by peer: socket write error
2011-12-03 18:00:32 DefaultHttpClient [INFO] Retrying request”…

為此，我找遍了中英文的一些網(wǎng)站，搜遍了能找的每個角落，發(fā)現(xiàn)了出現(xiàn)這種狀況的原理，該java異常在客戶端和服務器端都有可能發(fā)生，引起該異常的原因有兩個：

1，如果一端的Socket被關閉（或主動關閉，或因為異常退出而 引起的關閉），另一端仍發(fā)送數(shù)據(jù)，發(fā)送的第一個數(shù)據(jù)包引發(fā)該異常(Connect reset by peer)。

2，一端退出，但退出時并未關閉該連接，另一端如果在從連接中讀數(shù)據(jù)則拋出該異常（Connection reset）。簡單的說就是在連接斷開后的讀和寫操作引起的。

于是我簡單的認為通過設置一些socket的timeout時間，就能解決：

但是設置以后情況依然是那樣。

這個問題困擾了好幾天，每天都在思考和對比測試中，以求發(fā)現(xiàn)造成這個原因代碼的地方，我不禁思考，同樣數(shù)量的關鍵詞數(shù)量前提下，為什么之前批量查詢排名數(shù)據(jù)沒有出錯，而最近會頻繁報錯，這到底是為什么？是被請求的接口網(wǎng)站屏蔽掉了我們的服務器ip？這個理由也不是很充分，肯定是程序中某個地方?jīng)]有合理釋放掉connection的連接導致！

在這個思路的指引下，通過幾天連續(xù)的奮戰(zhàn)和實踐，今天終于發(fā)現(xiàn)了問題的本質(zhì)，那就是那個timer的方法導致的！情況是這樣的，這幾天，我在手動觸發(fā)一些批量任務，發(fā)現(xiàn)在過濾排名值為100的情況下，java的java.net.SocketException: Connection reset 這個錯會一直拋出，而且刷屏特別厲害，在仔細對照了timer的這段代碼

后，終于猛然醒悟，對！就是這里出問題了，我自己來分析一下：

一個函數(shù)值，它返回的值，是一個臨界值，但是我這個timer的方法中，判斷了返回的值如果是臨界值的話，會迫使它在10秒內(nèi)繼續(xù)執(zhí)行那個方法，而這個方法是要去獲取一個頁面中源代碼的一個特定數(shù)據(jù)，每次這個方法執(zhí)行會消耗掉幾十毫秒的時間，即相當于在這個時間內(nèi)，是建立了一個socket連接，但是由于它一直返回的是那個臨界值，所以這個方法會在10秒內(nèi)不停的建立socket連接以獲取數(shù)據(jù)，如果這個方法每次執(zhí)行時間大概是80ms（經(jīng)過測試，每個這樣的方法執(zhí)行時間為80毫秒左右），在10秒時間內(nèi)，會建立10*1000/80 = 125次socket連接，即每秒會建立起12.5個socket連接，再加上由于這個是過濾的程序，多個臨界值的情況會連續(xù)出現(xiàn)在一起，所以，在短暫的幾秒鐘內(nèi)，對同一個網(wǎng)站頁面的socket連接數(shù)會飆升的很高，達到幾百甚至上千，導致等待處理的請求連接數(shù)太高：

當初為什么會用這個定時器方法來讓一個方法多執(zhí)行幾遍，原因就是為了獲取一個數(shù)據(jù)的穩(wěn)定值，但是現(xiàn)在想來，帶來的負面影響代價是多么的大，產(chǎn)生的效果是不可小覷的，不過經(jīng)過幾天的綜合分析和測試，終于還是發(fā)現(xiàn)了這個罪魁禍首，問題解決后，心，一下子豁然了，可以安心睡覺了。。。

最新評論