Я должен проверить состояние диспетчера очередей IBM MQ перед открытием очереди. Мне нужно создать приложение-запросчик, проверив, активен ли QMgr или нет, затем вызовите сообщение msg или получите сообщение от MQ. Можно ли проверить статус,
пожалуйста, поделитесь фрагментами кода.
Спасибо
Вам НИКОГДА не нужно проверять QMgr перед открытием очереди. Как я ответил на похожий вопрос сегодня, предложенный дизайн очень, ОЧЕНЬ плохой дизайн. В результате асинхронный обмен сообщениями снова превращается в синхронный. Это связывает производителей сообщений с потребителями, вводит зависимости от местоположения и разрешения, разрушает кластеризацию, нарушает распределение и балансировку нагрузки WMQ, встраивает топологию сети в приложение и делает всю систему хрупкой. Пожалуйста, не обвиняйте WMQ в том, что он работает некорректно после того, как намеренно отключил все его лучшие функции, кроме фактических операций очереди/удаления из очереди.
Если ваше запрашивающее приложение проверяет активность QMgr, вам намного лучше использовать имя соединения с несколькими экземплярами и слой из двух или более функционально эквивалентных QMgr, которые могут получить доступ к кластеру. Пока один из QMgrs работает, приложение будет переключаться между ними, пока не найдет тот, к которому можно подключиться.
Если ваше отвечающее приложение проверяет, что QMgr активен, вам намного лучше просто попытаться подключиться. Приложения-респондеры никогда не должны переключаться на другой QMgr, так как это нарушает транзакционность и может оставить очереди необслуживаемыми. Вместо этого просто убедитесь, что в каждой очереди есть по крайней мере два дескриптора ввода из локальных приложений-ответчиков, которые не переключаются между QMgrs. (Это нормально, если сам QMgr отказывает с помощью аппаратной кластеризации или QMgr с несколькими экземплярами).
Если цель состоит в том, чтобы проверить наличие открытого дескриптора ввода в очереди, прежде чем помещать туда сообщения, лучший дизайн состоит в том, чтобы запрашивающее приложение не заботилось о том, в какой экземпляр очереди направляются сообщения, и вместо этого использовало инструментарий, встроенный в WMQ, чтобы либо перезапустить ответчик приложения, которые теряют свой дескриптор ввода, или отключить очередь, когда ничего не прослушивается.
