CLOSE_WAIT连接的Tomcat行为

Question

acceptCount队列在操作系统级别维护。 假设我们有一个10K的acceptCount队列。

状况-服务器由于依赖关系或网络问题之一而无法处理请求，或者花费了很长时间，并且在此期间所有客户端都超时。 最终，该队列具有10,000个CLOSE_WAIT连接。 现在，如果服务已再次备份并开始处理。 会清理CLOSE_WAIT连接队列吗？ 在这种情况下，tomcat将如何表现。

Answer 1

有关CLOSE_WAITS并达到最大连接数/线程数的一些技巧（我在WebLogic服务器中也遇到类似的问题，但这是常规技巧）

由于网络问题而释放卡住的线程：（如果根据业务允许）

1. 将超时值设置为所有远程调用（例如，DB / HTTP / EJB / ..）
2. 检查终止/杀死长时间运行的线程（请求）

在尝试任何解决方法之前，最好仔细检查并找出根本原因。

如果这是问题所在，则应在重负载周期结束后清除CLOSE_WAITS，但如果线程阻塞，则可能需要尽快重新启动以解决问题。

Answer 2

acceptCount队列在操作系统级别维护。

我假设您的意思是侦听积压队列。

假设我们有一个10k的acceptCount队列。

没有办法告诉。 您可以向操作系统提示您希望使用多长时间，但是操作系统可以上下调整它，并且没有API可以告诉您实际长度是多少。

最终，该队列具有10k CLOSE_WAIT连接。

不，不是。 CLOSE_WAIT状态不会在任何地方排队，并且监听积压队列与CLOSE_WAIT无关。

会清理CLOSE_WAIT队列吗？

没有这样的队列可以清理。

如果您真正要问的是重新启动进程，请清除所有处于CLOSE_WAIT状态的端口 ，答案是退出保留它们的进程即可。

但是，让Tomcat检测所有关闭的连接并自行关闭它们也是如此。 如果您有很多这些，那么真正的问题就是为什么它不会自动执行此操作。 这应该。

如果这是由一个请求转发到某个地方引起的，这听起来像是您的应用程序内部进行了同步，而不应该同步。