Конструктор MQQueueManager зависает, если диспетчер очереди недоступен и используется транзакция

Question

У меня проблема, когда вызов конструктора MQQueueManager зависает, если администратор очередей не работает.

У меня открыт TransactionScope с EnterpriseOptions.Full, когда я вызываю конструктор для MQQueueManager.Если MQ не работает (или, возможно, пытается подключиться, когда QM выходит из строя), то этот вызов зависает.Даже если срок действия транзакции истекает, это не вызывает исключение тайм-аута в транзакции.

Если у меня нет открытой области транзакции, когда я выполняю соединение, я никогда не смогу заставить MQQueueManager участвовать в транзакциипосле этой точки.

ТАК, если MQ может выйти из строя (что он делает ....), как я могу остановить зависание очереди при установлении соединения.Я использую Управляемый клиент из MQ 6.0.2.5.

Я добавил код, чтобы прояснить вопрос:

TransactionOptions opt = new TransactionOptions();
opt.IsolationLevel = IsolationLevel.Serializable;
opt.Timeout = new TimeSpan(0, 0, 20);
TransactionScopeOption ScopeOption = TransactionScopeOption.Required;

using (TransactionScope tran = 
    new TransactionScope
        (ScopeOption, 
        opt, 
        EnterpriseServicesInteropOption.Full))
{
    //This line hangs if MQ is down, doesn't backout or throw a 2059.
    var m_qMgr = new MQQueueManager(QueueManager, Channel, Hostname);
    tran.Complete();
}

Answer 1

Я вижу две возможности для зависания. Во-первых, это более низкий уровень, чем WMQ, а во-вторых, что код WMQ может иметь необработанное исключение. Давайте посмотрим на оба из них.

Если предположить, что TCP зависает при попытке построить сокет, почему он работает, когда WMQ работает, но не работает? Один ответ - если слушатель WMQ остался включенным после того, как QMgr вышел из строя. В этом случае слушатель принимает сокет, но ему нечего передать. Это часто случается, если слушатель запускается с runmqlsr, а не как объект слушателя QMgr. Это практически неизбежно при использовании inetd в качестве слушателя. Вы не упомянули версию на стороне QMgr. Какая версия WMQ и как запускается слушатель? На какой платформе работает QMgr?

Вторая возможность, которую я рассматриваю, - это несоответствие конфигурации и опций. WMQ выполнит однофазную фиксацию с любой установкой клиента, но вы запрашиваете координацию с Windows в качестве контроллера транзакций. В режиме клиента для этого требуется расширенный транзакционный клиент (a.k.a. XTC). Компонент XTC является частью установки сервера WMQ и фактически лицензируется как сервер WMQ. Другими словами, если вы платите за сервер WMQ на своем хосте Windows, вы имеете право установить полный сервер WMQ и / или компонент XTC там. Компонент XTC - это то, что предоставляет mqic32xa.dll, который обеспечивает транзакционность XA через клиентские соединения WMQ.

Часто люди, которые не знают о последствиях лицензирования, берут классы XA dll или Java / JMS XA и помещают их в свою установку клиента WMQ. Если классы XA не установлены с использованием носителя WMQ Server, это может привести к непредсказуемым результатам, таким как то, что вы видите. Это особенно верно, если файлы поддержки XA и установка клиента WMQ находятся на разных уровнях пакета Fix Pack или, что еще хуже, в разных версиях.

Как была установлена ​​поддержка XA на вашем сервере Windows? Если что-то меньше, чем с носителя WMQ Server, у вас может быть неправильная установка. В любом случае, было бы целесообразно использовать последний пакет Fix Pack, так как 6.0.2.5 достаточно устарел. Список исправлений для v6.0.2.9 содержит несколько APAR, связанных с .Net, включая IZ54336 , который гласит «Ошибка протокола AMQ9456 на сервере и ошибка hconn 2018 на клиенте во время попытки mqconn управляемым приложением .NET».

Для правильной установки WMQ для вашего приложения запрещенным способом является получение носителя WMQ v7.0 Server и установка клиента WMQ с него. Выберите Extended Transactional Client для установки. После завершения примените последний пакет исправлений. Классы .Net были интегрированы в базовый продукт WMQ в версии 7 и полностью поддерживаются. Использование носителя сервера делает поддержку XA доступной при установке клиента. В дополнение к v7, являющемуся намного лучшей реализацией .Net, версия v6 устарела через 12 месяцев, поэтому использование v7 теперь избавит вас от конвертации позже или потери поддержки. Клиент v7 совместим с v6 QMgr, но вы, конечно, не получите новую функциональность v7.

Вы можете сделать примерно то же самое на носителе v6 Server, но обязательно установите последний пакет исправлений, чтобы получить выгоду от всех примененных исправлений .Net. Некоторые из новых функциональных возможностей v7 также были предоставлены в сервисном потоке, так что вы также получаете это преимущество.

Загрузить пробную версию WMQ Server можно по адресу http://bit.ly/WMQTrial
Вы можете скачать последнюю версию Fix Pack по адресу http://bit.ly/WMQFixes

Answer 2

Конструктор MQQueueManager имеет перегрузку, которая принимает HashTable свойств.Исходя из моего опыта, при вызове MQ из приложения .NET вам необходимо установить для TRANSPORT_PROPERTY значение TRANSPORT_MQSERIES_MANAGED.

например,

 // set up the connection settings for the queue manager.
 var settings = new Hashtable {{MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED}};
 var qm = new MQQueueManager("yourQueueManagerName", settings);

Вы можете найти немного больше информации об этом свойстве здесь .

Надеюсь, это поможет.Я слишком хорошо знаю, как бороться с MQ.