Jetty 8長連接上的又一個坑
2018-07-20 來源：編程學習網(wǎng)
Jetty 8 長連接的超時斷開連接的機制：超時連接機制針對IO傳輸過程中的數(shù)據(jù)阻塞時間超過一定閾值時，斷開該連接。阻塞指當前處于數(shù)據(jù)傳輸階段，但是連續(xù)指定時間內(nèi)都沒有發(fā)出或者接收到任何數(shù)據(jù)時，Jetty系統(tǒng)斷開該連接。強調(diào)一下，只有在數(shù)據(jù)傳輸過程中才會有超時機制。在服務(wù)端處理已經(jīng)收到的數(shù)據(jù)時是不會檢測該超時時間的。
下面看一下具體的代碼實現(xiàn)。在jetty 8.1.17版本中，由以下代碼控制一個連接的空閑、非空閑和斷開檢查方法，在SelectChannelEndpoint類中：
/* ------------------------------------------------------------ */ public void setCheckForIdle(boolean check) { if (check) { _idleTimestamp=System.currentTimeMillis(); _checkIdle=true; } else _checkIdle=false; } /* ------------------------------------------------------------ */ public boolean isCheckForIdle() { return _checkIdle; } /* ------------------------------------------------------------ */ protected void notIdle() { _idleTimestamp=System.currentTimeMillis(); } /* ------------------------------------------------------------ */ public void checkIdleTimestamp(long now) { if (isCheckForIdle() && _maxIdleTime>0) { final long idleForMs=now-_idleTimestamp; if (idleForMs>_maxIdleTime) { // Don't idle out again until onIdleExpired task completes. setCheckForIdle(false); _manager.dispatch(new Runnable() { public void run() { try { onIdleExpired(idleForMs); } finally { setCheckForIdle(true); } } }); } } }
幾個關(guān)鍵點地方：當數(shù)據(jù)傳輸?shù)倪^程中，發(fā)現(xiàn)無法接收到和寫出數(shù)據(jù)時，會調(diào)用setCheckForIdle(true)方法，從當前時間點開始計時，當后臺select線程發(fā)現(xiàn)該連接的空閑時間達到閾值時，則調(diào)用onIdleExpired方法。還有一種場景是，在一個請求結(jié)束后，立即將該請求置為空閑狀態(tài)。直到連接關(guān)閉或者該連接上面來了新的請求。另外，每個新的連接建立時，會在構(gòu)造函數(shù)中默認調(diào)用一次該方法設(shè)置連接為空閑狀態(tài)。
在哪些情況下會調(diào)用相反的設(shè)置呢，即將該連接置為非空閑狀態(tài)的setCheckForIdle(false)方法，和刷新當前的idle時間方法notIdle()呢？第一個方法每次收到一個請求的數(shù)據(jù)提交后端的servlet的時候調(diào)用，后一個方法在每次刷出或者讀到數(shù)據(jù)時調(diào)用。這樣確保后端的servlet在處理數(shù)據(jù)時，不至于因為處理時間過長而被自己的select線程給關(guān)閉了。
這一次jetty的bug正是出在上述的每個請求的數(shù)據(jù)收集完成進入后端處理之前發(fā)生的。看如下代碼：
AsyncHttpConnection類中，handle方法：
@Override public Connection handle() throws IOException { Connection connection = this; boolean some_progress=false; boolean progress=true; try { setCurrentConnection(this); // don't check for idle while dispatched (unless blocking IO is done). _asyncEndp.setCheckForIdle(false); // While progress and the connection has not changed while (progress && connection==this) { progress=false; try { // Handle resumed request if (_request._async.isAsync()) { if (_request._async.isDispatchable()) handleRequest(); } // else Parse more input else if (!_parser.isComplete() && _parser.parseAvailable()) progress=true; // Generate more output if (_generator.isCommitted() && !_generator.isComplete() && !_endp.isOutputShutdown() && !_request.getAsyncContinuation().isAsyncStarted()) if (_generator.flushBuffer()>0) progress=true; // Flush output _endp.flush(); // Has any IO been done by the endpoint itself since last loop if (_asyncEndp.hasProgressed()) progress=true; } catch (HttpException e) { if (LOG.isDebugEnabled()) { LOG.debug("uri="+_uri); LOG.debug("fields="+_requestFields); LOG.debug(e); } progress=true; _generator.sendError(e.getStatus(), e.getReason(), null, true); } finally { some_progress|=progress; // Is this request/response round complete and are fully flushed? boolean parserComplete = _parser.isComplete(); boolean generatorComplete = _generator.isComplete(); boolean complete = parserComplete && generatorComplete; if (parserComplete) { if (generatorComplete) { // Reset the parser/generator progress=true; // look for a switched connection instance? if (_response.getStatus()==HttpStatus.SWITCHING_PROTOCOLS_101) { Connection switched=(Connection)_request.getAttribute("org.eclipse.jetty.io.Connection"); if (switched!=null) connection=switched; } reset(); // TODO Is this still required? if (!_generator.isPersistent() && !_endp.isOutputShutdown()) { LOG.warn("Safety net oshut!!! IF YOU SEE THIS, PLEASE RAISE BUGZILLA"); _endp.shutdownOutput(); } } else { // We have finished parsing, but not generating so // we must not be interested in reading until we // have finished generating and we reset the generator _readInterested = false; LOG.debug("Disabled read interest while writing response {}", _endp); } } if (!complete && _request.getAsyncContinuation().isAsyncStarted()) { // The request is suspended, so even though progress has been made, // exit the while loop by setting progress to false LOG.debug("suspended {}",this); progress=false; } } } } finally { setCurrentConnection(null); // If we are not suspended if (!_request.getAsyncContinuation().isAsyncStarted()) { // return buffers _parser.returnBuffers(); _generator.returnBuffers(); // reenable idle checking unless request is suspended _asyncEndp.setCheckForIdle(true); } // Safety net to catch spinning if (some_progress) _total_no_progress=0; else { _total_no_progress++; if (NO_PROGRESS_INFO>0 && _total_no_progress%NO_PROGRESS_INFO==0 && (NO_PROGRESS_CLOSE<=0 || _total_no_progress< NO_PROGRESS_CLOSE)) LOG.info("EndPoint making no progress: "+_total_no_progress+" "+_endp+" "+this); if (NO_PROGRESS_CLOSE>0 && _total_no_progress==NO_PROGRESS_CLOSE) { LOG.warn("Closing EndPoint making no progress: "+_total_no_progress+" "+_endp+" "+this); if (_endp instanceof SelectChannelEndPoint) ((SelectChannelEndPoint)_endp).getChannel().close(); } } } return connection; }
可以看到，在handle方法進入時，調(diào)用了一次：
// don't check for idle while dispatched (unless blocking IO is done). _asyncEndp.setCheckForIdle(false);
如果當前連接是一個短連接，那么這里調(diào)用完全沒問題。請求處理完成后本來就可能立即斷開連接。但是如果是一個長連接，該連接在處理完請求后，可能“休息”一段時間繼續(xù)處理新的請求，那么就問題就來了，從該代碼看，jetty在handle方法的while循環(huán)中處理多個請求，這樣可以避免同一個連接上面的多個請求被分到不同的線程中處理，而是綁定在一個線程上面處理，當長連接上面的請求比較“密集”（請求之間間隔極短）時，該while會循環(huán)多次，有兩種情況會進入該請求：1、一個請求上面的數(shù)據(jù)沒有處理完，即
// else Parse more input else if (!_parser.isComplete() && _parser.parseAvailable()) progress=true;
這個代碼控制的。
另外當一個請求處理完了，也會在finally里面走到progess=true上面。
// Is this request/response round complete and are fully flushed? boolean parserComplete = _parser.isComplete(); boolean generatorComplete = _generator.isComplete(); boolean complete = parserComplete && generatorComplete; if (parserComplete) { if (generatorComplete) { // Reset the parser/generator progress=true;
由這個控制。
問題出在第二個上面，當一個請求處理完成后，連接會被置為空閑狀態(tài)。但是這里將progess設(shè)置為true，那么while循環(huán)立即準備讀取下一個請求的數(shù)據(jù)，但是并沒有將連接置為非空閑狀態(tài)，此時如果服務(wù)端進入耗時較長的處理流程，那么可能不等到客戶端超時，連接就被后臺檢查空閑連接的線程斷開了。
因此這里很明顯，jetty有bug，應該在最后的這段代碼出補充
// don't check for idle while dispatched (unless blocking IO is done). _asyncEndp.setCheckForIdle(false);
這個調(diào)用�；蛘呤窃诿看芜M入while循環(huán)時調(diào)用，而不是只在進入handle時調(diào)用。
該問題發(fā)生有幾個關(guān)鍵點：長連接上面持續(xù)不斷有新請求過來，并且新請求發(fā)起的時間距離上一個請求完成的時間間隔非常短。經(jīng)過實測，python的http客戶端在處理長連接上面，請求間隔非常短。而其他語言和庫編寫的客戶端測試程序都有比較長的間隔，導致問題不易重現(xiàn)。附一個jetty的簡易http長連接測試程序：
import httplib count=0 conn = httplib.HTTPConnection("127.0.0.1", timeout=600) while (count < 1000000): conn.request("PUT","/") res = conn.getresponse() print res.status, res.reason print res.read() count += 1
在jetty上面講超時時間配置盡可能短，在servlet里面處理請求時休眠一個大于等于超時時間的值，配合上述客戶端，很容易重現(xiàn)問題。
文章來源：http://codefine.co/2822.html
版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。
下一篇:談?wù)劸幾g和運行
