最近拿到一個工程,不停的報socket write error,雖然不影響正常使用,但是真的很煩,而且會影響日志的記錄.所以決定找到這個問題的答案:
excepion的堆棧信息如下:
Exception Processing ErrorPage[errorCode=404, location=/404.jsp]
ClientAbortException: java.net.SocketException: Connection reset by peer: socket write error
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:327)
at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:293)
at org.apache.catalina.connector.Response.flushBuffer(Response.java:544)
at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:286)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:746)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:433)
at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuffer.java:304)
at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:991)
at org.apache.coyote.Response.action(Response.java:182)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:322)
13 more第一反映是google一下.發現真是個大眾性的問題,無數人在問,很多人在解答,答案不一
有說weblogic問題的,有說apache+tomcat問題的..但很多都沒有提問者出來確認問題解決.
這說明產生這個問題的原因很多.現說說我看到的,認為的可能的原因:
解釋一:
http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=121&threadID=21359&messageID=136779這個跟數據庫沒有關系，當客戶端發出請求（request）后，如果還沒有完全獲得服務端的響應（response），客戶端與服務器段的連接斷開（例如斷網、按了“停止”按鈕、或者客戶端瀏覽器關閉等），服務器端就會拋出此Exception
解釋二:
http://blogger.org.cn/blog/more.asp?name=lisawater&id=8841這個問題一般是客戶端在連接還沒有完全建立的時候就取消連接，比如用戶按了瀏覽器上面的“停止”按鈕，一般來說沒有什么問題。但是如果頻繁出現，就表示很多客戶端連接到Apache服務器的響應時間太長了，可能是網絡的問題或者服務器性能問題 可能你的網絡連接存在一些問題，你的數據傳輸的時候，可能由于時間等待的太久，但是server段設置的連接檢驗時間限制一定，那么就可能出現這種情況的！
解釋三:
http://www.kehui.net/html/article/33/33915.html經常出現的
Connection reset by peer: 原因可能是多方面的，不過更常見的原因是：①：服務器的并發連接數超過了其承載量，服務器會將其中一些連接Down掉；②：客戶關掉了瀏覽器，而服務器還在給客戶端發送數據；③：瀏覽器端按了Stop
上邊這些解釋意思大概差不多,不過側重點不同,詳細程度不同,有的從現象,有的從原因,有的從原理.
感覺這些解答是對的,但是造成這個現象的原因依然是多樣的.什么才是造成我這個工程的原因呢 ?我并沒有出現上述的情況,但依然大量存在這種exception幾乎每次都出現.
下邊介紹一下我拿到的工程,這個工程是基于appfuse變化來的,很多東西類似.因為對這個exception沒有概念
當時第一反映是排除法,一個個去掉工程中的各個框架,找到原因為止.測試的結果是和sitemesh有關,但記憶中我也用過sitemesh(
如果你對sitemesh不了解看這里)沒出過這樣的錯誤.建立一個sitemesh的工程,測試沒問題,把對應的配置文件也弄過來全部都一樣,問題出現了.仔細分析一下,發現直觀原因是sitemesh的decorators目錄下的裝飾文件中的出現<ww:head/>的情況就會出這個exception,刪掉不相關的東西.再測試,問題又沒了.再次分析.發現
<ww:head>和一個配置的error頁面同時存在的時候才會有這個問題.去掉任何一個都不出現.為什么呢 ?
仔細看一下這個error頁面404.jsp,發現一個問題,404.jsp也使用了sitemesh.分析一下,發現一個問題.如果<ww:head/>
引發404錯誤,跳轉到4.4.jsp頁面,404頁面被filter攔截,再次引入decorators中的頁面,也就再次解析<ww:head/>再次造成404錯誤.這時個死循環.這下明白了.只要確認<ww:head/>會產生404錯誤就可以了.確認了一下是這個問題.
原因找到了,分析一下:
在使用sitemesh同時配置一個異常頁面的時候太容易產生這個問題了.同時異常頁面沒有被sitemesh exclude
只要decorators中的頁面出現問題,就很容易會出現這個exception
常出現的原因就是引入不存在的文件,js ,image,css等
原因上邊分析了,死循環.
總結:
如果你使用sitemesh,如果你出現這個異常.第一個應該看的時decorator中的文件是否會產生異常.
另外<ww:head/>是webwork2.2之后才加入的,使用下來發現了很多問題.這里不一一列舉了.建議盡量少用,
如果你想看一下效果:
這里
http://www.tkk7.com/Files/dreamstone/sitemesh.rar下載工程,導入eclipse,添加需要的jar文件,然后直接訪問404.jsp就出現了