При отключении от WebSphere MQ с клиентом C # TCP-соединения все еще находятся в состоянии CLOSE_WAIT - PullRequest
Новая
       0

При отключении от WebSphere MQ с клиентом C # TCP-соединения все еще находятся в состоянии CLOSE_WAIT

3 голосов
/ 17 июня 2010

Я отключаюсь от 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 из командной строки я получаю длинный список подключений к серверу MQ, и состояние этих подключений равно CLOSE_WAIT .

Есть идеи, почему TCP-соединения не закрываются полностью? Есть ли способ, которым я мог бы убить тех из кода? В настоящее время мне придется перезапустить клиентское приложение, которое очищает открытые соединения.

Версия WebSphere MQ - 6.0.2.6, а библиотеки .NET - из MQ 7.

1 Ответ

1 голос
/ 22 июня 2010

В руководстве по миграции есть раздел под названием Обновление клиента WebSphere MQ с версии 6.0 до версии 7.0 , в котором предлагается возможное объяснение. В нем говорится, что начиная с v7 настройки TCP хранятся в файле конфигурации клиента. Так что если вы включили TCP Keepalive в реестре Windows, клиент v7 проигнорирует его. Формат и расположение файла описаны в файле конфигурации клиента WebSphere MQ .

Конечно, чтобы это было проблемой, должна быть утечка сокета. Вы не упомянули, какая у вас версия клиента WMQ V7, но в файлах README Fix Pack действительно отображается количество APAR, связанных с утечками сокетов, невозможностью очистки после отключений и т. Д. Ни в одном из них не упоминается C # или .Net, но проблем с подключением / отключением достаточно, чтобы его можно было обновить.

Итак, первое и самое простое решение - добавить TCP Keepalive в файл конфигурации клиента и посмотреть, поможет ли это. Отключите общий доступ к соединению, пока вы там. Это не должно быть фактором, но также не должно пропускать сокеты. Не повредит. Далее следует применить Fix Pack 7.0.1.2 (последний на момент написания этой статьи) и посмотреть, решит ли это проблему. После этого время PMR. Надеюсь, это поможет.

...