When disconnecting from WebSphere MQ with C# client TCP connections are still in CLOSE_WAIT status

Question

I am disconnecting from MQQueue and MQQueueManager with the following code:

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;

And I get the following log entries for this:

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

But after few hours when I run netstat -n command from command prompt I get a long list of connections to MQ server and the State in those connections is CLOSE_WAIT.

Any ideas why the TCP connections doesn't get fully closed? Are there any way that I could kill those from code? Currently I'll have to restart the client app which cleans up the open connections.

WebSphere MQ version is 6.0.2.6 and the .NET libraries are from MQ 7.

Answer 1

Looking in the Migration Guide there's a section called Upgrading a WebSphere MQ client from Version 6.0 to Version 7.0 which suggests a possible explanation. It states that as of v7 the TCP tuning is stored in the client configuration file. So if you have enabled TCP Keepalive in the Windows registry, the v7 client will ignore it. The format and location of the file is described in WebSphere MQ client configuration file.

Of course for this to be the problem, there has to be a socket leak. You did not mention which version of WMQ V7 client you have but the Fix Pack README files do show a number of APARs related to socket leaks, failure to clean up after disconnects and so forth. None of these directly mention C# or .Net but there are enough problems around connection/disconnection issues to make it worth an upgrade.

So first & easiest fix to attempt is to add TCP Keepalive to the client configuration file and see if it helps. Disable connection sharing while you are in there as well. It's not supposed to be a factor but then it's not supposed to leak sockets either. Can't hurt. Next is to apply Fix Pack 7.0.1.2 (latest as of this writing) and see if that fixes the problem. After that, it's PMR time. Hope that helps.