位置: IT常识 - 正文
Broken Pipe问题及其解决(broken pipe write failed)
发布时间：2024-01-05推荐整理分享Broken Pipe问题及其解决(broken pipe write failed)，希望有所帮助，仅作参考，欢迎阅读内容。
文章相关热门搜索词:broken pipe怎么解决,broken pipe异常分析及解决,brokenpipeerror broken pipe,broken pipe from,broken pipe or closed connection,brokenpipeerror broken pipe,broken pipe异常分析及解决,brokenpipeerror broken pipe,内容如对您有帮助，希望把文章链接给更多的朋友！
简单来说，Broken Pipe 意味着一台机器正在尝试从管道读取数据或向管道写入数据，而管道另一端的机器已经死亡或终止。现在，由于连接已关闭，应建立新连接以进一步传输数据，否则数据传输将停止。
它是如何发生的？此问题的最常见原因之一是客户端在执行任何操作（如加载页面或下载附件）时关闭打开的连接。当使用 Nginx 之类的代理/负载均衡器（例如关闭 Web 浏览器甚至简单地取消下载）或连接速度很慢时，强制关闭某些连接也会发生这种情况。
一个简单的场景：浏览器向服务器请求资源，作为响应，服务器向浏览器返回响应。如果在服务器向浏览器发送响应时用户关闭了浏览器怎么办？服务器与浏览器之间的连接意外关闭。然后这会导致 Broken Pipe，该异常被称为 java.io.IOException: Broken Pipe in Java。
这也可能发生在任何中断客户端和服务器之间连接的事情上，包括性能问题甚至网络间歇性问题。
并非每个 Broken Pipe 异常都是开发人员的错
导致此异常的可能因素：最终用户数量由于Broken Pipe的主要原因之一是用户的行为（在服务器完成发送响应之前意外关闭活动浏览器会话），最终用户数量的增加增加了Broken Pipe的机会。
重响应负载来自服务器的重响应需要大量时间才能传输到客户端，而这个巨大的时间跨度可能是 Broken Pipe 的情况。
服务器超时如果 Web 服务器在等于服务器设置的超时值的特定时间内无法得到服务的响应，它会关闭与客户端的连接，返回 503: Gateway Timeout 并因此导致 Broken Pipe。
断管异常是危险信号吗？公平地说，这不是一个危险信号，因为它很大程度上是由用户的正常行为引起的，并且总是有可能由于某些故障而关闭服务。但是，如果服务器一次运行在相对大量的用户请求上，那么不仅是 Broken Pipe，而且任何异常似乎都会造成问题。
在我的例子中，由于高网络流量，日志被损坏的管道异常淹没。因为，写入文件（I/O 操作）是服务器执行的昂贵操作之一，想象一下服务器被与 Broken Pipe 相关的异常淹没，并且服务器必须投入大量资源才能将该异常堆栈跟踪写入日志文件。这导致服务器响应缓慢并使其迟缓。
在这一点上，我意识到，当扩展到大流量时，YES BROKEN PIPE EXCEPTION 是一个红色信号。
处理或移除破损管道的挑战 该系统使用 Wildfly 10.1 作为应用程序服务器，并在 JavaEE 7 上编写。处理这种情况对我来说不是小菜一碟，因为：
在本地或 QA 环境中复制此异常需要正确对齐所有行星（开个玩笑），但是是的，这太难了。
在 Java 中处理异常很容易，只要在 catch 块中捕获异常即可。未处理异常的性质：java.io.IOException: Broken pipe 是这样的，它从 Wildfly 容器中引发并在堆栈跟踪中注销，而不是被困在 catch 块中。现在，想象一下必须处理无法从代码中捕获的异常。天哪！！！！
您永远不会知道，哪个请求引发了问题，因为服务器收到大量请求，其中任何一个都可能是异常的原因。将日志与套接字端点一起添加到每个 REST 端点是不可行的。
修复 java.io.IOException : Broken Pipe 最后，经过这么多断章取义的谈话，这里是主要部分（希望它值得等待）。
从系统中删除异常的两种方法是：
调查异常的根本原因，并消除它。 使用适当的日志记录或某些操作来优雅地处理异常。 消除根本原因 要求用户不要意外关闭连接 这是不可能的，看在上帝的份上
减少 api 响应负载这在某种程度上是可以实现的，但是在遗留系统中，对大量数据进行操作，重写所有逻辑以使 api 响应不重也不在所有情况下都是可行的。
增加服务器超时Nginx 有一个名为proxy_read_timeout的变量，它的默认值为 60s，增加这个值也会最大限度地减少 Broken Pipe 的机会。
即使在消除了在这种情况下本身很难检测到的确切根本原因之后，我们也不能完全排除断管的存在。我们可以吗？
因此，下一个解决方案是优雅地处理 Broken Pipe。
处理 java.io.IOException: Broken Pipe抑制来自 logger 本身的日志 如果您使用 log4j 作为日志管理器，将以下配置添加到 log4j.properties 将有助于摆脱由于 Broken Pipe 导致的异常泛滥日志。
log4j.logger.org.apache.catalina.connector.ClientAbortException = ERROR, console, cloudAppenderlog4j.additivity.org.apache.catalina.connector.ClientAbortException = false在 Wildfly 中升级 Resteasy 我们使用 JAX-RS 的 Resteasy 实现在 Java 中实现 REST，Resteasy v3.0.19 与 Wildfly 10.1 捆绑在一起。希望能在 resteasy 本身中找到一些修复，我开始深入研究 Resteasy 的发行说明，发现在 Resteasy-Client v3.1.1 之后，可以从代码中捕获 Unhandled Exception: java.io.IOException，不像容器暴露它直接进入logtrace。因此，Resteasy Client 的升级版本允许我们通过 Global Exception Handler 来处理异常（后面会介绍）。 在 Wildfly 中升级 Resteasy 的步骤
查找 Resteasy 分发 jar的位置： Resteasy 分发 jar 的位置位于： WILDFLY_HOME/modules/system/layers/base/org/jboss/resteasy/resteasy-jaxrs/main 文件名：resteasy-jaxrs-3.0.19 .Final.jar
从Resteasy 下载处下载resteasy 目标版本（3.1.1 及以上）的 zip 文件
在临时目录中解压文件。它里面还有另外两个 zip 文件： resteasy-jboss-modules-3.1.1.Final-mavenized.zip和 resteasy-jboss-modules-3.1.1.Final.zip
在以下位置解压缩两个 .zip 文件： WILDFLY_HOME/modules/system/layers/base
在pom.xml中更新 resteasy 依赖项的版本
<dependency> <groupId>org.jboss.resteasy</groupId> <artifactId>resteasy-jaxrs</artifactId> <version>3.1.1.Final</version> <scope>provided</scope></dependency>使用 Global Exception Handler 我进一步从 java 代码本身添加了 Generic Exception Mapper，以捕获和处理 Broken Pipe。 我的最终方法 虽然我已经收集了多种技术来解决这个问题，但以下是我实际实现的东西：
将 Wildfly 升级到 v11.0，因为它自动附带了 Resteasy v3.1.1（我真正想要的版本）捆绑在其中。 通过 Global Exception Handler 处理异常 有了这个，Broken Pipe 的问题现在只存在于旧的日志档案中.
参考文献：https://dev.to/bishwapoudel/how-i-fixed-java-io-ioexception-broken-pipe-in-java-wildfly-10-1-86k
上一篇：最奢华的iPhone 4S是什么(最奢华的女士腕表)
下一篇：网站国际化 多语言处理工具i18n安装使用方法(网站国际化方案)
