Разрешено ли более одного менеджера очереди на хост/порт?

Question

При настройке MQQueueConnectionFactory мы инициализировать его следующим образом:

MQQueueConnectionFactory factory = new MQQueueConnectionFactory(); 

factory.setQueueManager(queueManager); 

factory.setTransportType(CommonConstants.WMQ_CM_CLIENT); 
factory.setHostName(host); 
factory.setPort(port); 
factory.setChannel(channel); 

Особенно мы устанавливаем имя менеджера очередей. Из этого шаблона кажется, что имя менеджера очереди необходимо для полной идентификации диспетчера очереди. Можно было бы сделать вывод, что на том же хосте и порту может случиться другой менеджер очереди. Это возможно?

Однако при установке the connection name list указать заново цели не имя менеджера очереди необходимо:

public void setConnectionNameList(java.lang.String hosts) throws javax.jms.JMSException

Определяет хосты, к которым клиент будет пытаться подключиться к после его разрыва соединения , Список имен соединений представляет собой разделенный запятыми список пар портов хоста/ip. например. 127.0.0.1 (1414), host2.example.com (1400) Значение по умолчанию этого свойства является 'локальным (1414)' Нулевого или пустая строка для обозначения Localhost (1414)

При установке в client reconnect options два варианта, как представляется, важное значение в этом контексте:

• WMQ_CLIENT_RECONNECT - Повторное подключение к любому из менеджеров очередей, указанных в списке имя подключения
• WMQ_CLIENT_RECONNECT_Q_MGR - Подключитесь к одному менеджеру очередей мы были первоначально подключен к. Это вызовет MQRC_RECONNECT_QMID_MISMATCH, если менеджер очереди, к которому он пытается подключиться (указан в списке имен соединений), имеет другой QMID для менеджера очереди, изначально связанного с.

Эти Документации делают не ясно, если несколько менеджеров очередей за тот же хост/порт возможны. Сравните это с Oracle, где несколько сервисов могут обслуживаться одним и тем же слушателем.

У нас есть два менеджера очередей, которые прослушивают разные хосты/порты, которые имеют разные имена. Мы хотим использовать один из этих менеджеров очереди как диспетчер отказоустойчивости в списке имен соединений. Вопрос в том, что диспетчер очереди однозначно идентифицирован только хостом и портом?

Answer 1

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

Может быть только один прослушиватель, привязанный к определенному порту и интерфейсу. Поэтому, если слушатель является беспорядочным (слушает на всех интерфейсах), на порт есть только один порт. Если хост имеет несколько интерфейсов, отдельные слушатели могут быть связаны на одном и том же порту на каждом из интерфейсов. Поскольку слушатель является дочерним процессом диспетчера очереди, импликация - это только один QMgr, который может прослушивать заданную комбинацию address(port).

Имя QMgr не обязательно должно присутствовать в запросе на соединение, полученном QMgr. Если имя QMgr пуст, соединение успешно выполняется с любым QMgr, к которому обращается запрос на соединение, при условии, что QMgr не отклоняет его для неправильного пароля, проверки сертификата или других ошибок. Однако, если имя QMgr равно в запросе на подключение, то должен соответствовать имени QMgr, к которому подключено соединение.

Соединитель Namelist (более правильно CONNAME) представляет собой список разделенных запятыми комбинаций address(port), которые имеют право на получение запрашиваемого соединения.

Многопользовательские QMgrs имеют два адреса и один порт. Они активны только по одному адресу, а канал, указывающий на них, должен иметь оба адреса, чтобы они могли надежно подключаться. Однако он не должен иметь имя QMgr.

Но есть еще один тип HA, в котором есть несколько эквивалентных QMgrs, каждый с разными именами, к которым клиент может подключиться. Это особенно верно, когда клиент запрашивает информацию из системы записи, но сам по себе не является системой записи. Такой клиент не нуждается в прослушивании в хорошо известной очереди. Вместо этого он подключается к любому одному из уровней QMgrs клиентского соединения, создает динамическую очередь «Reply-To» и отправляет запросы в систему прослушивания записей в кластерной очереди в сети MQ где-то. В этом случае клиент не указывает имя QMgr и, таким образом, использует поведение MQ в принятии любого QMgr, к которому он подключается.

Наконец, MQ уже давно имеет таблицу определения клиентских каналов или файлы CCDT. До того, как у нас был мультиэкземпляр CONNAME, CCDT предоставил возможность подключения к любому из нескольких QMgr. Вместо того, чтобы вводить имя QMgr в CCDT, MQ Admin помещает символические имена. Например, если для обработки зарплаты было 3 QMgrs, имена QMgr в их записи CCDT могут быть PAY01, PAY02 и PAY03, ни одна из которых не соответствует фактическим именам QMgr. Каждый из них имеет address(port), указывающий на один из трех QMgr. Затем разработчик указывает имя QMgr *PAY, а клиент MQ будет выбирать среди всех записей CCDT с первыми тремя символами, соответствующими «PAY». С помощью этого и нескольких других вариантов можно было снова подключить клиентский диск MQ, но при этом заглушка клиента MQ инкапсулирует логику того, нужно ли циклически переключаться между получателями, повторять последний подключенный адрес или что угодно.

Из этого шаблона кажется, что имя менеджера очереди необходимо, чтобы полностью идентифицировал диспетчер очереди. Можно было бы сделать вывод, что на том же хосте и порту может случиться другой менеджер очередей. Возможно ли это ?

No.

У нас есть два менеджера очереди прослушивания на разных хостах/портов, которые имеют разные названия. Мы хотим использовать один из этих менеджеров очереди как диспетчер отказоустойчивости в списке имен соединений. Вопрос в том, является ли диспетчер очереди однозначно идентифицированным только хостом и портом?

Убедитесь, что имя QMGR является пустым по запросу и указать оба address(port) комбинации в CONNAME и вы должны быть хорошо идти.

См.: Role of the client channel definition table, и в частности в этом разделе Queue manager groups in the CCDT. Здесь также полезен раздел на Examples of channel weighting and affinity.

Наконец, убедитесь, что вы используете современный клиент. Поскольку клиенты MQ могут подключаться к любому QMgr с прямым или обратным уровнем, можно разработать клиент v9.0 и подключиться к v7.1 QMgr. Конечно, предоставленная функциональность основана на самой низкой версии клиента или QMgr, поэтому вы не получаете JMS 1.2 с клиентом v9.0 и старинным QMgr. Тем не менее, вы do получите все улучшения производительности и исправления ошибок в более поздних версиях клиента.Если вы не в последней версии клиента (или последней один поддерживаемый вашим JEE сервер) затем загрузить один на:

• SupportPac MQC75
• SupportPac MQC8
• SupportPac MQC9

Answer 2

Так же, как любой другой серверное приложение, прослушивающее уникальный TCP-порт, IBM MQ Queue Manager прослушивает уникальный TCP-порт на хосте. Таким образом, никакие два менеджера очередей не могут прослушивать один и тот же порт на хосте. Для подключения к диспетчеру очереди требуется комбинация хоста и порта (имя соединения a.k.a или короткое сообщение CONNAME).

Список имен соединений используется для указания нескольких хостов &. Клиенты MQ используют эту информацию для автоматического повторного подключения к резервному экземпляру диспетчера очереди нескольких экземпляров или диспетчера очереди резервного копирования в случае снижения активного диспетчера очереди.

Приходит к вашему сценарию: вы можете оставить имя менеджера очереди на фабрике соединений и просто указать комбинацию нескольких хостов и портов с помощью метода setConnectionNameList. Очень важно: вы должны убедиться, что оба менеджера очереди имеют одинаковые определения объектов, такие как канал подключения к серверу для подключения приложения, очереди/темы, полномочия и т. Д. В противном случае ваше приложение может выйти из строя.