问题场景
在公司项目中做配置迁移的时候，上线后突然出现线上问题，查日志发现报错Broken pipe，翻译成中文就是管道损坏，还是在过滤器中被捕获的异常，看的我一头雾水
问题分析
发现 Broken pipe"错误通常表示在写入数据时连接的另一端已经关闭。这个错误通常出现在网络通信中，特别是在客户端和服务器之间建立的连接。
这个错误的常见原因有
- 客户端或服务器在写入数据之前关闭了连接：当服务器或客户端提前关闭了连接时，另一端尝试写入数据时就会触发"Broken pipe"错误。这可能是由于连接超时、连接中断或意外关闭引起的。
- 数据写入速度过慢：如果写入数据的速度比对端读取数据的速度慢，那么对端可能会在等待数据的过程中关闭连接，从而导致"Broken pipe"错误。
回到项目
套用上述线索去查这个接口，这个接口本身运行时正常的，没有任何报错，唯一异常的是发现这个接口执行用了三十多秒，一连查五六个个Broken pipe相关的报错的，都是同样的情况
所以问题就分析明白了
因为接口执行时间过长，已经超过三十秒，所以服务器段和客户浏览器端的连接因为超时的原因就断开了，而且我还特意去找前端同事去确认了下，发现确实是和浏览器有关，也就是接口请求超过一定时间，浏览器会主动关闭这个连接，不同的浏览器的连接最大保持时间不同，常见的谷歌浏览器应该是可以保持30秒，所以接口将数据返回给前端的时候，会在服务器tomcat/undertow进行网络通信将返回值响应回前端时层抛出Broken pipe异常，而后被过滤器层捕获并打印报错
问题解决
修改客户端和浏览器段的最大连接时长（理论可行，但我没试过）
- 服务器端去修改tomcat或undertow的最大连接时长
- 前端也要配置连接时长和服务器端一致
优化接口
因为我这里接口执行时间确实不正常(公司老项目的屎山代码，里面一个校验逻辑循环调用了几百次sql)，所以扩展思考下，可能时因为配置迁移时对mysql数据库的配置做了些改动，导致sql连接数上限降低，更容易出现sql连接数打满，所以我这里通过优化接口，大幅降低接口执行时间和sql执行频率，即解决该问题
过滤器中捕获报错 Broken pipe
)
