Получение кода причины ошибки 2059 на клиенте MQ (C #) при повторном подключении к QueueManager через некоторое время - PullRequest
2 голосов
/ 04 июня 2010

Я не могу повторно подключиться к MQQueueManager через некоторое время как исключение (код причины 2059 - MQRC_Q_MGR_NOT_AVAILABLE) выбрасывается при создании нового объекта MQQueueManager. Мое клиентское приложение написано на .NET / C #, и я запускаю его на Win2003.

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

Мой код подключения:

    Hashtable properties = new Hashtable();
    properties.Add( MQC.HOST_NAME_PROPERTY, Host );
    properties.Add( MQC.PORT_PROPERTY, Port );
    properties.Add( MQC.USER_ID_PROPERTY, UserId );
    properties.Add( MQC.PASSWORD_PROPERTY, Password );
    properties.Add( MQC.CHANNEL_PROPERTY, ChannelName );
    properties.Add( MQC.TRANSPORT_PROPERTY, TransportType );
    // Following line throws an exception randomly
    MQQueueManager queueManager = new MQQueueManager( qmName, properties );

Трассировка стека:

    Source: amqmdnet
    CompletionCode: 2
    ReasonCode: 2059
    Reason: 2059
    Stack Trace:
     at IBM.WMQ.MQBase.throwNewMQException()
     at IBM.WMQ.MQQueueManager.Connect(String queueManagerName)
     at IBM.WMQ.MQQueueManager..ctor(String qmName, Hashtable properties)
     at WebSphereMQOutboundAdapter.WebSphereMQOutbound.ConnectToWebSphereMQ()

Ответы [ 2 ]

2 голосов
/ 04 июня 2010

Соединения для каждого потока, поэтому, если вы пытаетесь создать новое соединение, пока предыдущий объект QMgr еще создается, вы получите это. Если вы закроете предыдущее соединение и уничтожите объект перед созданием нового объекта, все будет в порядке. Поскольку очереди и другие объекты WMQ зависят от дескриптора соединения, их также необходимо будет уничтожить, а затем заново создать после установления нового соединения.

Конечно, есть несколько других объяснений этого поведения, но они гораздо менее вероятны. Например, возможно, что выход канала или (в WMQ v7) конфигурация может ограничивать количество одновременных соединений с данного IP-адреса. Когда соединение разорвано, а не закрыто, агент канала, удерживающий соединение на стороне QMgr, должен установить тайм-аут, прежде чем QMgr увидит, что соединение закрыто. Если ограничение соединения установлено, эти «призрачные» соединения уменьшают доступный пул. Но, как я уже сказал, это гораздо реже, чем программы, не очищающие старые объекты перед попыткой повторного подключения.

Существует также вероятность того, что это ошибка. Чтобы уменьшить эту возможность и по ряду других причин, таких как WMQ v6, выходящий из строя в следующем году, я бы рекомендовал использовать WMQ v7.0.1.2 для этого проекта как на стороне клиента, так и на стороне сервера. В общем, вы можете использовать клиент v7.0.1.2 с сервером v6.0.x, если вы придерживаетесь функциональности v6. Помимо прочего, код .Net лучше интегрирован в v7, а пакеты поддержки Cat-3 теперь включены в базовый установочный носитель, а не в отдельную загрузку.

1 голос
/ 14 июля 2014

После нескольких месяцев борьбы с этой проблемой и поддержкой IBM лучшее решение, которое я нашел, - это изменить код подключения / отключения в драйвере IBM MQ.

Вместо того, чтобы вызывать manager.Disconnect () и manager.Close () для каждого GET / PUT, подключайтесь один раз, а затем повторно подключайтесь, только если у вас есть какое-то исключение (например, потеря соединения).

Я выяснил, что в IBM MQ Driver существует какая-то ошибка, которая кэширует некоторую информацию для каждого соединения / разъединения. Когда этот буфер заполнен, приложение перестает подключаться.

Версия драйвера (клиентская DLL) У меня есть эта проблема: 7.0.1.6

...