java.io.IOException:管道破裂

我们目前正在将一个遗留应用程序迁移到Jetty。我有一个例外，关于一根断了的管子

• 爪哇6
• 码头8.1.8
• Spring 3.2.0

我正在尝试将Glassfish web应用程序迁移到Jetty。在我们的测试环境中，我们使用负载平衡器，一切正常。我们的客户工作没有任何问题

WARN  [2013-04-03 13:34:28,963] com.myapp.bbb.config.MvcDefaultConfig$1: Handler execution resulted in exception
! org.eclipse.jetty.io.EofException: null
! at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:914)
! at org.eclipse.jetty.http.HttpGenerator.complete(HttpGenerator.java:798)
! at org.eclipse.jetty.server.AbstractHttpConnection.completeResponse(AbstractHttpConnection.java:642)
! at org.eclipse.jetty.server.Response.complete(Response.java:1234)
! at org.eclipse.jetty.server.Response.sendError(Response.java:404)
! at org.eclipse.jetty.server.Response.sendError(Response.java:416)
! at org.springframework.web.servlet.DispatcherServlet.noHandlerFound(DispatcherServlet.java:1111)
! at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:898)
! at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:856)
! at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:915)
! at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:811)
! at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
! at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:796)
! at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
! at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:669)
! at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1336)
! at com.magnetdigital.maggy.dropwizard.head2get.Head2GetFilter.doFilter(Head2GetFilter.java:22)
! at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307)
! at com.yammer.dropwizard.servlets.ThreadNameFilter.doFilter(ThreadNameFilter.java:29)
! at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307)
! at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453)
! at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
! at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072)
! at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382)
! at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
! at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006)
! at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
! at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
! at com.yammer.metrics.jetty.InstrumentedHandler.handle(InstrumentedHandler.java:200)
! at org.eclipse.jetty.server.handler.GzipHandler.handle(GzipHandler.java:275)
! at com.yammer.dropwizard.jetty.BiDiGzipHandler.handle(BiDiGzipHandler.java:123)
! at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
! at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
! at org.eclipse.jetty.server.Server.handle(Server.java:365)
! at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:485)
! at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
! at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:926)
! at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:988)
! at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:635)
! at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
! at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
! at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.run(BlockingChannelConnector.java:298)
! at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
! at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
! at java.lang.Thread.run(Thread.java:662)
Caused by: ! java.io.IOException: Broken pipe
! at sun.nio.ch.FileDispatcher.write0(Native Method)
! at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)
! at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:69)
! at sun.nio.ch.IOUtil.write(IOUtil.java:26)
! at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
! at org.eclipse.jetty.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:293)
! at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.flush(BlockingChannelConnector.java:253)
! at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:850)
!... 44 common frames omitted

当我检查stacktrace时，我看到异常总是由404请求触发的

org.springframework.web.servlet.DispatcherServlet.noHandlerFound（DispatcherServlet.java:1111）

• 为什么我会有这个例外
• 如何在本地计算机上复制此异常

  ---

我遇到的“管道破裂”最常见的原因是，一台机器（通过插座进行通信的一对机器）在通信完成之前关闭了插座的末端。其中大约一半是因为在该套接字上进行通信的程序已终止

如果发送字节的程序将它们发送出去，并立即关闭套接字或自行终止，则套接字有可能在发送和读取字节之前停止工作

尝试在关闭套接字的任何位置暂停，然后再让程序终止，看看是否有帮助

---

仅供参考：“管道”和“套接字”是有时可以互换使用的术语。

增加响应。getBufferSize（）

---

获取缓冲区大小并与要传输的字节进行比较

我同意@arcy的观点，问题出在客户端，在我的案例中是因为nginx，让我详细说明一下 我使用nginx作为前端（因此我可以分发负载、ssl等），并使用

proxy\u-passhttp://127.0.0.1:8080

将适当的请求转发给tomcat

nginx变量

proxy\u read\u timeout

有一个60秒的默认值，这应该足够了，但是在某些峰值时刻，我的设置会出现java.io.IOException错误：断管更改该值将有助于解决根本原因（60秒应该足够了）

---

注意：我做了一个新的回答，这样我可以对我的案例进行更多的扩展（这是我在互联网上查找了很多次后发现的关于此错误的唯一一次提及）

基本上，发生的情况是，您的用户要么关闭浏览器选项卡，要么在通信完成之前导航到另一个页面。您的Web服务器（Jetty）生成此异常，因为它无法发送剩余的字节

org.eclipse.jetty.io.EofException: null
! at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:914)
! at org.eclipse.jetty.http.HttpGenerator.complete(HttpGenerator.java:798)
! at org.eclipse.jetty.server.AbstractHttpConnection.completeResponse(AbstractHttpConnection.java:642)
! 

这不是应用程序逻辑方面的错误。这仅仅是由于用户行为。你的代码本身没有错

您可以做两件事：

忽略此特定异常，以便不记录它

使您的代码更加高效/紧凑，以便传输更少的数据。（不一定是选项！）

---

您可能尚未设置输出文件。

错误消息表明客户端已关闭连接，而服务器仍在尝试写入响应

有关更多详细信息，请参阅此链接：

---

我几乎知道创建此异常的请求，但我无法成功创建类似的请求。你有没有办法通过卷曲或其他方式产生一个破裂的管道？rcook是正确的，看起来客户端在退出之前没有完全消耗响应…当用户在完全加载页面之前离开页面时，通常会出现这种情况。我发现我的问题是客户端有一个超时设置，当等待时间超过时，客户端将关闭连接。之后，服务器端希望将响应刷新到客户端，但流已经关闭。于是“管道破裂”的问题发生了。您可以调整客户端超时设置以消除这种情况。因此，我已将此异常处理为警告级别。显然，负责发送信息的代码必须置于用户控制之外，即，如果用户可以单击某个按钮并导致线程退出，则您将任由用户摆布。在不了解您的应用程序的情况下，很难提出任何具体建议，但您可以考虑确保负责完成套接字发送的代码位于非守护进程（或“在守护进程”？）线程上，即在应用程序终止时不会自动退出的线程，以便它可以完成发送。这假设你控制了发送者，当然……你好，我正在练习，这是这个问题的一行答案。arcy的回答是否为您提供了有价值的信息？你知道改变它的意义吗？JDK中没有

bufferSize（）

方法，也没有任何变体拼写，“将[thebufferSize]与要传输的字节进行比较”是没有意义的。答案是胡说八道。@ VimalUnMalnAtRajaAn考虑留下一些容易被OP跟踪的代码片段，因为我的答案长度对答案没有任何说明，所以它看起来很好，因为它对OP很有帮助，如果不是这样的话，那么考虑编辑并最终删除这个答案。在我的案例中，当我将弹出窗口设置为从后端加载，并将超时设置为自动关闭时，它会在加载弹出窗口之前关闭，以防您（像我一样）想找到一种方法来忽略这种特定类型的IOException（而不是忽略所有其他类型的IOException），然后，这篇博文很好地展示了如何在Spring MVC中实现这一点：