最近拿到一个工程,不停的报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.Http11BaseProtocolHttp11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)atorg.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)atorg.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)atorg.apache.tomcat.util.threads.ThreadPoolHttp11ConnectionHandler.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.ThreadPoolHttp11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)atorg.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)atorg.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)atorg.apache.tomcat.util.threads.ThreadPoolControlRunnable.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问题的…但很多都没有提问者出来确认问题解决.
这说明产生这个问题的原因很多.现说说我看到的,认为的可能的原因:
- 解释一:
这个跟数据库没有关系，当客户端发出请求（request）后，如果还没有完全获得服务端的响应（response），客户端与服务器段的连接断开（例如断网、按了“停止”按钮、或者客户端浏览器关闭等），服务器端就会抛出此Exception
- 解释二:
这个问题一般是客户端在连接还没有完全建立的时候就取消连接，比如用户按了浏览器上面的“停止”按钮，一般来说没有什么问题。但是如果频繁出现，就表示很多客户端连接到Apache服务器的响应时间太长了，可能是网络的问题或者服务器性能问题 可能你的网络连接存在一些问题，你的数据传输的时候，可能由于时间等待的太久，但是server段设置的连接检验时间限制一定，那么就可能出现这种情况的！
- 解释三:
http://www.kehui.net/html/article/33/33915.html
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之后才加入的,使用下来发现了很多问题.这里不一一列举了.建议尽量少用,
如果你想看一下效果:
想要实时关注更多干货好文，扫描下图关注：
