Конструктор MQQueueManager зависает, если диспетчер очереди недоступен и используется транзакция
У меня есть проблема, когда вызов конструктора 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();
}
2 ответа
Я вижу две возможности для зависания. Первая заключается в том, что это более низкий уровень, чем WMQ, а вторая - в том, что код WMQ может иметь необработанное исключение. Давайте рассмотрим оба варианта.
Если предположить, что TCP зависает, пытаясь создать сокет, то почему он работает, когда WMQ работает, но не работает? Один из ответов - если приемник WMQ остался на месте после того, как QMgr упал. В этом случае слушатель принимает сокет, но ему нечего передать. Такое часто случается, если приемник запущен с помощью runmqlsr, а не как объект QMgr listener. Это практически неизбежно, если в качестве слушателя используется inetd. Вы не упомянули версию на стороне QMgr. Какая версия WMQ и как запущен слушатель? На какой платформе работает QMgr?
Вторая возможность, которую я рассматриваю, - это несоответствие конфигурации и опций. WMQ будет выполнять 1-фазную фиксацию при любой установке клиента, но то, что вы просите его сделать, это координировать работу с Windows в качестве контроллера транзакций. В клиентском режиме для этого требуется Extended Transactional Client (он же XTC). Компонент XTC является частью установки WMQ Server и фактически лицензируется как WMQ Server. Другими словами, если вы платите за сервер WMQ на вашем хосте Windows, то вы имеете право установить там полный сервер WMQ и/или компонент XTC. Компонент XTC - это то, что поставляет mqic32xa.dll, которая обеспечивает транзакционность XA через клиентские соединения WMQ.
Много раз люди, не знающие о последствиях лицензирования, хватали XA dll или Java/JMS XA классы и бросали их на свою установку WMQ клиента. Если классы XA не установлены с носителя WMQ Server, это может привести к непредсказуемым результатам, подобным тем, что вы видите. Это особенно верно, если файлы поддержки XA и установка клиента WMQ имеют разные уровни пакетов исправлений или, что еще хуже, разные версии.
Как была установлена поддержка XA на вашем сервере Windows? Если не с носителя WMQ Server, то, возможно, у вас некорректная установка. В любом случае, желательно использовать последний пакет исправлений, поскольку 6.0.2.5 уже довольно устарел. Список исправлений для версии 6.0.2.9 содержит несколько APAR, связанных с .Net, включая IZ54336, который гласит: "Ошибка протокола AMQ9456 наблюдается на сервере и ошибка 2018 hconn на клиенте во время попытки mqconn управляемым приложением .NET."
Чтобы правильно установить WMQ для вашего приложения, рекомендуется получить носитель WMQ v7.0 Server и установить с него клиент WMQ. Выберите Extended Transactional Client для установки. После завершения установки примените последний пакет исправлений. Классы .Net были интегрированы в базовый продукт WMQ в версии 7 и полностью поддерживаются. Использование серверного носителя делает поддержку XA доступной при установке клиента. В дополнение к тому, что v7 является гораздо лучшей реализацией .Net, v6 выходит из эксплуатации через 12 месяцев, поэтому использование v7 сейчас избавит вас от необходимости конвертации позже или потери поддержки. Клиент v7 совместим с QMgr v6, но вы, конечно, не получите новых функциональных возможностей v7.
Вы можете делать примерно то же самое с носителя v6 Server, но обязательно установите последний Fix Pack, чтобы получить преимущества всех исправлений .Net, которые были применены. Некоторые из новых функциональных возможностей v7 также были предоставлены в сервисном потоке, так что вы получите и это преимущество.
Вы можете скачать пробную версию WMQ Server по адресу http://bit.ly/WMQTrial
Вы можете скачать последний Fix Pack по адресу http://bit.ly/WMQFixes
Конструктор 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.