当从WebSphere MQ断开与C＃客户端的TCP连接仍处于CLOSE_WAIT状态

我从MQQUEUE和MQQueueManager断开与下面的代码：当从WebSphere MQ断开与C＃客户端的TCP连接仍处于CLOSE_WAIT状态

 
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命令我得到的那些连接到MQ服务器和国家连接的一个长长的清单是CLOSE_WAIT。

任何想法为什么TCP连接没有完全关闭？有什么办法可以杀死那些代码吗？目前，我将不得不重新启动客户端应用程序，清理打开的连接。

WebSphere MQ的版本是6.0.2.6和.NET库从MQ 7

来源

2010-06-17 Tommi L.

寻找的迁移指南中有一个叫Upgrading a WebSphere MQ client from Version 6.0 to Version 7.0节这表明一个可能的解释。它指出，从v7起，TCP调优存储在客户端配置文件中。因此，如果您在Windows注册表中启用了TCP Keepalive，则v7客户端将忽略它。该文件的格式和位置在WebSphere MQ client configuration file中描述。

当然，对于这个问题，必须有一个套接字泄漏。您没有提及您拥有哪个版本的WMQ V7客户端，但Fix Pack自述文件确实显示了一些与套接字泄漏相关的APAR，断开后无法清理等等。这些都没有直接提到C＃或.Net，但是在连接/断开连接问题上存在足够的问题以使其值得升级。

因此，首先&最简单的尝试修复方法是将TCP Keepalive添加到客户端配置文件并查看是否有帮助。当你在那里时禁用连接共享。这不应该是一个因素，但它不应该泄漏套接字。不能伤害。接下来是应用Fix Pack 7.0.1.2（本文最新），看看是否解决了这个问题。之后，这是PMR时间。希望有所帮助。

来源

2010-06-22 01:00:29

我不知道为什么这被接受为答案。提出了多种解决方法，其中一个“可能”解决了这个问题，但没有提供明确的解决方案。拿下一票。 – theKing 2013-09-03 23:59:46

问题中没有足够的信息来提供确定的解决方案。根据所提供的信息，我提供了OP显然足以解决问题的信息。所以我采取了一个投票，因为OP没有麻烦更新他的问题？ downvote没有得到更好的答案，如果你问自己的问题，很可能会导致你被你想要回复的人忽视。恕我直言，这既不富有成效也不合适。 – 2013-09-04 03:25:02

@theKing说这是一个用户，而不是一个主持人 - 但你有没有注意到这个职位是三岁以上？ – 2013-09-10 08:20:19

当从WebSphere MQ断开与C＃客户端的TCP连接仍处于CLOSE_WAIT状态

回答

相关问题