当使用C#客户端与WebSphere MQ断开连接时，TCP连接仍处于CLOSE_WAIT状态

Question

我正在使用以下代码与MQQueue和MQQueueManager断开连接：

Queue.Close();
log.Info( "Queue IsOpen: " + Queue.IsOpen.ToString() );
Queue = null;
QueueManager.Disconnect();
QueueManager.Close();
log.Info( "QM IsOpen: " + QueueManager.IsOpen.ToString() );
log.Info( "QM IsConnected: " + QueueManager.IsConnected.ToString() );
QueueManager = null;

这是我的日志记录：

Queue IsOpen: false
QM IsOpen: false
QM IsConnected: false

但是几个小时后，当我从命令提示符运行netstat -n命令时，我会得到一个长列表，其中的连接状态为CLOSE_WAIT。

有什么想法为什么TCP连接没有完全关闭吗？是否有任何方法可以从代码中杀死它们？目前，我必须重新启动客户端应用程序以清理打开的连接。

WebSphere MQ版本为6.0.2.6，.NET库来自MQ 7。

- Tommi L.

Answer 1

在迁移指南中有一个名为从版本6.0升级WebSphere MQ客户端到版本7.0的部分，其中提供了可能的解释。它指出，从v7开始，TCP调整存储在客户端配置文件中。因此，如果您已在Windows注册表中启用了TCP Keepalive，则v7客户端将忽略它。文件的格式和位置在WebSphere MQ客户端配置文件中有描述。

当然，要出现这个问题，必须存在套接字泄漏。您没有提到您使用的WMQ V7客户端版本，但修补程序README文件显示了许多与套接字泄漏、断开连接后未能清理等相关的APAR。虽然没有直接涉及C#或.Net，但是由于连接/断开连接问题足够多，因此值得升级。

所以，首先尝试最简单的修复方法是在客户端配置文件中添加TCP Keepalive，并查看是否有帮助。在那里禁用连接共享也是一个好主意。虽然它不应该是一个因素，但它也不应该泄漏套接字。接下来是应用Fix Pack 7.0.1.2（截至本文撰写时的最新版本），看看是否解决了问题。之后，就是PMR时间了。希望这有所帮助。

- T.Rob

---

我不确定为什么这被接受为答案。虽然有多种解决方法被建议，其中一个“可能”可以解决问题，但在这里没有提供明确的解决方案。我要撤销投票。 - theKing

问题中没有足够的信息提供明确的解决方案。根据所给的信息，我提供了显然足够的信息供 OP 修复问题。所以我因为 OP 没有更新他的问题而被踩了一下？这个踩并没有为你带来更好的答案，反而可能导致你被那些你想要回应你自己问题的人忽视。在我看来，这既不生产也不合适。 - T.Rob

@theKing 作为一个用户说，而不是一个管理员 - 但你注意到这篇帖子已经超过三年了吗？ - Andrew Barber