是什么导致了 WildFly / Undertow 断管错误？答案

【问题标题】：What is causing this WildFly / Undertow broken pipe error?是什么导致了 WildFly / Undertow 断管错误？
【发布时间】：2014-09-26 14:09:47
【问题描述】：

我在 NetBeans 下运行的 WildFly 8.1.0.Final 安装中似乎随机出现以下错误：

08:51:09,742 ERROR [io.undertow.request] (default task-40) Blocking request failed   HttpServerExchange{ GET /web/faces/javax.faces.resource/dynamiccontent.properties}:   java.lang.RuntimeException: java.io.IOException: Broken pipe
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
Caused by: java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.8.0_20]
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.8.0_20]
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.8.0_20]
at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.8.0_20]
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:470) [rt.jar:1.8.0_20]
at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:531)
at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:256)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:625)
at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
... 9 more

请求的页面似乎可以正常加载，因此除了日志中的异常之外，我没有注意到任何中断。有什么想法吗？

【问题讨论】：

标签： wildfly-8

【解决方案1】：

我也遇到过类似的问题，感谢this response 的想法，我稍微改进了一点。我要揭露我的案子。

我正在使用 Java (Java 7) (javax.ws.rs) 创建一个 REST API，并将其部署在 JBoss 服务器 (8.x) 上。

我的 Api 响应这些路径：

/myapi/a
/myapi/a?filer=myfilter

所以我这样编码：

private static final String FILTER = "filter";

@GET
@Path("/a")
@Produces(MediaType.APPLICATION_JSON)
public Object
foo(@Context UriInfo requestInfo) {
    LOG.info("Http request: GET /myapi/a");
    if (requestParameters.getQueryParameters().containsKey(FILTER)) {
            return foo(requestInfo.getQueryParameters().get(FILTER));
    } 
    // no params
    return ...
}


public Object foo(List<String> filter) {
    LOG.info(" > Requested filter"); 
    return ...;
}

但我有时从服务器收到了这个异常（不是我的代码）由java.io.IOException: Broken pipe引起的UT005023: Exception handling request to ... sessionState: org.jboss.resteasy.spi.UnhandledException: Response is committed, can't handle exception

调查它我发现了一些非常有趣的东西：它只能从 Safari 浏览器而不是 Chrome 中重现它。所以呢？关键是 Safari 有一个 Chrome 没有的功能：当 Safari 自动完成请求时，它会发送请求。在按下 enter 按钮之前，Chrome 不会发送请求。这很重要，因为只有在以下情况下才会出现错误：

使用 Safari 的自动完成功能请求 /a?filter=f
向 /a 请求（按回车键）

此时，我不知道原因（它与 http 标头有关）=> 作为 stephen-c，问题是您正在尝试做一些需要更改HTTP 响应标头...在标头发送后

[编辑]

我几乎可以肯定 (99%) 我们无法处理该异常。基本上它是说你丢失了一个请求，作为警告，服务器告诉你你不会处理它。

还有另一种方法可以重新创建异常：尝试将手指放在F5 或CMD-R。您将创建数百个请求...但您会丢失其中一些（与池线程、工作人员等有关），并且您会看到这些丢失请求的异常。 p>

我决定不再担心这个了。

【讨论】：

【解决方案2】：

我也有同样的警告，但仅限于 Firefox。 Daniel.lichtenberger 的post 很好地解释了这个问题以及如何解决它。

总结一下，Firefox 的RCWN 会同时发出两个请求并取消最慢的请求，从而导致管道中断警告。要禁用 RCWN，请在 Firefox 中输入 about:config 并禁用 network.http.rcwn.enable

【讨论】：

【解决方案3】：

如果您在 IE 中发送 multipart/form-data 请求，您必须将隐藏类型附加到表单中，像这样

        <form>
...
            <!-- for IE -->
            <input type='hidden' name='_4ie' value='for IE'>
        </form>

【讨论】：