Jersey 客户端中的套接字处于 CLOSE_WAIT 状态
我使用 Jersey 1.4、ApacheHttpClient 和 Apache MultiThreadedHttpConnectionManager 类来管理连接。对于 HttpConnectionManager，我将 staleCheckingEnabled 设置为 true，将 maxConnectionsPerHost 设置为 1000，将 maxTotalConnections 设置为 1000。其他均为默认值。我们在 Tomcat 中运行，并使用 Jersey 客户端与多个外部主机建立连接。
我注意到，经过一小段时间后，我将开始看到与 Tomcat 进程关联的处于 CLOSE_WAIT 状态的套接字。使用 tcpdump 进行的一些监控显示，外部主机似乎在一段时间后关闭连接，但在我们这边并没有关闭。通常socket读队列中有一些数据，通常是24字节。连接使用 https，数据似乎已加密，所以我不确定它是什么。
我已检查以确保创建的 ClientRequest 对象已关闭。 CLOSE_WAIT 中的套接字似乎确实被回收了，并且我们没有耗尽任何资源，至少目前是这样。我不确定外部服务器上发生了什么。
我的问题是，这正常吗？我应该担心吗？
谢谢，
约翰
I am using Jersey 1.4, the ApacheHttpClient, and the Apache MultiThreadedHttpConnectionManager class to manage connections. For the HttpConnectionManager, I set staleCheckingEnabled to true, maxConnectionsPerHost to 1000 and maxTotalConnections to 1000. Everything else is default. We are running in Tomcat and making connections out to multiple external hosts using the Jersey client.
I have noticed that after after a short period of time I will begin to see sockets in a CLOSE_WAIT state that are associated with the Tomcat process. Some monitoring with tcpdump shows that the external hosts appear to be closing the connection after some time but it's not getting closed on our end. Usually there is some data in the socket read queue, often 24 bytes. The connections are using https and the data seems to be encrypted so I'm not sure what it is.
I have checked to be sure that the ClientRequest objects that get created are closed. The sockets in CLOSE_WAIT do seem to get recycled and we're not running out of any resources, at least at this time. I'm not sure what's happening on the external servers.
My question is, is this normal and should I be concerned?
Thanks,
John
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这可能是防火墙或远程服务器等设备导致 TCP 会话超时。您可以使用 Wireshark 分析 HTTPS 的数据包捕获，如其 SSL 页面上所述：
http://wiki.wireshark.org/SSL staleCheckingEnabled
标志仅在您实际使用连接时发出检查，因此您在不需要网络资源（TCP 会话）时不会使用它们。
This is likely to be a device such as the firewall or the remote server timing out the TCP session. You can analyze packet captures of HTTPS using Wireshark as described on their SSL page:
http://wiki.wireshark.org/SSL
The staleCheckingEnabled flag only issues the check when you go to actually use the connection so you aren't using network resources (TCP sessions) when they aren't needed.