MQRC_UNKNOWN_ALIAS_BASE_Q при соединении с кластером IBM MQ с использованием CCDT и Spring Boot JMSTemplate

Question

MQRC_UNKNOWN_ALIAS_BASE_Q при соединении с кластером IBM MQ с использованием CCDT и Spring Boot JMSTemplate

У меня есть приложение Spring Boot, использующее JMSListener + IBMConnectionFactory + CCDT для подключения к кластеру IBM MQ.

Установите следующие свойства соединения: - URL-адрес, указывающий на сгенерированный файл ccdt - Имя пользователя (пароль не требуется, поскольку среда тестирования) - Имя администратора очередей НЕ определено - так как это задача кластера, которую нужно решить, и несколько результатов Google, включая несколько стековых потоков те указывают, что в моем случае qmgr должен быть установлен в пустую строку.

Когда мой Spring Boot JMSListener пытается подключиться к очереди, возникает следующая ошибка MQRC_UNKNOWN_ALIAS_BASE_Q:

2019-01-29 11:05:00.329 WARN  [thread:DefaultMessageListenerContainer-44][class:org.springframework.jms.listener.DefaultMessageListenerContainer:892] - Setup of JMS message listener invoker failed for destination 'MY.Q.ALIAS' - trying to recover. Cause: JMSWMQ2008: Failed to open MQ queue 'MY.Q.ALIAS'.; nested exception is com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2082' ('MQRC_UNKNOWN_ALIAS_BASE_Q').
com.ibm.msg.client.jms.DetailedInvalidDestinationException: JMSWMQ2008: Failed to open MQ queue 'MY.Q.ALIAS'.
        at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:513)
        at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:215)

В журнале ошибок MQ я вижу следующее:

01/29/2019 03:08:05 PM - Process(27185.478) User(mqm) Program(amqrmppa)
                    Host(myhost) Installation(Installation1)
                    VRMF(9.0.0.5) QMgr(MyQMGR)

AMQ9999: Channel 'MyCHL' to host 'MyIP' ended abnormally.

EXPLANATION:
The channel program running under process ID 27185 for channel 'MyCHL'
ended abnormally. The host name is 'MyIP'; in some cases the host name
cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error logs to
determine the cause of the failure. Note that this message can be excluded
completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
found in the System Administration Guide.
----- amqrmrsa.c : 938 --------------------------------------------------------
01/29/2019 03:15:14 PM - Process(27185.498) User(mqm) Program(amqrmppa)
                    Host(myhost) Installation(Installation1)
                    VRMF(9.0.0.5) QMgr(MyQMGR)

AMQ9209: Connection to host 'MyIP' for channel 'MyCHL' closed.

EXPLANATION:
An error occurred receiving data from 'MyIP' over TCP/IP.  The connection
to the remote host has unexpectedly terminated.

The channel name is 'MyCHL'; in some cases it cannot be determined and so
is shown as '????'.
ACTION:
Tell the systems administrator.

Так как журнал ошибок MQ содержит QMgr (MyQMGR), значение MyQMGR, которое я не установил в свойствах соединения, я предполагаю, что маршрутизация выглядит нормально: кластер MQ определил, какой qmgr использовать.

Псевдоним существует и указывает на существующий q. Бот цель q и псевдоним добавляются в кластер с помощью команды CLUSTER(clustname).

Что может быть не так?

1

spring-boot ibm-mq spring-jms jmstemplate

Источник

user2334539 29 янв '19 в 14:57

1 ответ

Решение

Другие вопросы по тегам spring-boot ibm-mq spring-jms jmstemplate

user7264620 29 янв '19 в 17:35 2019-01-29 17:35 · Accepted Answer · 2019-01-29 17:35

Короткий ответ

MQ Clustering не используется для потребительского приложения, чтобы найти очередь для получения сообщений GET.
Кластеризация MQ используется, когда приложение производителя помещает сообщения, чтобы направить их к месту назначения.

дальнейшее чтение

Кластеризация используется при отправке сообщений, чтобы помочь обеспечить балансировку нагрузки и несколько экземпляров кластеризованной очереди. В некоторых случаях люди используют это для горячего / холодного переключения при сбое, имея два экземпляра очереди и сохраняя только одинPUT(ENABLED),

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

До версии 7.1 существовало только два способа предоставления доступа к удаленным кластерным очередям:

ИспользуяQALIAS:
- Определить местныйQALIASдля которого TARGET установлено имя кластерной очереди
  Обратите внимание на этоQALIASсамо по себе не нужно кластеризовать.
- Разрешить положить на местный QALIAS,
Предоставить разрешения PUT для SYSTEM.CLUSTER.TRANSMIT.QUEUE,

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

На 7.1 IBM добавила новое необязательное поведение, это было предоставлено с настройкой ClusterQueueAccessControl=RQMName в Security строфа из qm.ini, Если это включено (это не значение по умолчанию), то вы можете фактически предоставить разрешение для приложения на PUT для удаленных кластеризованных очередей напрямую без необходимости локального QALIAS,

Кластеризация не предназначена для использования приложений, таких как ваш пример JMSListener.

Приложение, которое будет потреблять от любого QLOCAL (кластеризованный или нет) должен быть подключен к администратору очередей, где QLOCAL определено.

Если у вас есть ситуация, когда есть несколько экземпляров кластеризованных QLOCAL которые PUT(ENABLED)вам необходимо убедиться, что потребители подключены напрямую к каждому администратору очередей, на котором размещен экземпляр.

На основании вашего комментария у вас есть CCDT с записью, такой как:

CHANNEL('MyCHL') CHLTYPE(CLNTCONN) QMNAME('MyQMGR') CONNAME('node1url(port1),node2url(port2)')

Если прослушиваются два разных администратора очередей с разными именами администратора очередей node1url(port1) а также node2url(port2)Тогда у вас есть разные способы сделать это со стороны приложения.

Когда вы указываете QMNAME для подключения к приложению, вы ожидаете, что имя будет соответствовать администратору очередей, к которому вы подключаетесь, если только оно не соответствует одному из следующих:

Если вы укажете *MyQMGR он найдет канал или каналы с QMNAME('MyQMGR') и выберите один и подключитесь, и не будет принудительно устанавливать, что имя удаленного администратора очередей должно совпадать.
Если в вашем CCDT у вас есть QNAME(''), ему присвоено значение NULL, тогда в вашем приложении вы можете указать пустое имя администратора очередей или только пробел, и он найдет эту запись в CCDT и не будет принудительно указывать, что имя удаленного администратора очередей должно совпадать.
В вашем приложении вы указываете имя администратора очередей как *MQ будет использовать любой канал в CCDT и не будет обеспечивать соответствие имени удаленного администратора очередей.

Одним из ограничений CCDT является то, что имя канала должно быть уникальным в CCDT. Даже из QMNAME отличается, вы не можете иметь вторую запись с тем же именем канала.

При подключении вы попадаете на вход двумя CONNAMEи подключаюсь к первому IP(port)добрались бы только до второго IP(port) если при подключении первое недоступно, MQ попробует второе, или если вы подключены и у вас включена функция RECONNECT, а затем при первом отключении MQ попытается подключиться к первому, а затем ко второму.

Если вы хотите иметь обе кластерные очереди PUT(ENABLED) чтобы получить трафик, вы хотите иметь возможность специально подключаться к каждому из двух администраторов очередей для чтения этих очередей.

Я бы посоветовал вам добавить новый канал в каждом администраторе очередей, который имеет другое конкретное имя QM, которое также отличается от существующего имени, примерно так:

CHANNEL('MyCHL1') CHLTYPE(CLNTCONN) QMNAME('MyQMGR1') CONNAME('node1url(port1)')
CHANNEL('MyCHL2') CHLTYPE(CLNTCONN) QMNAME('MyQMGR2') CONNAME('node2url(port2)')

Это будет в дополнение к существующей записи.

Для размещения компонентов вы можете продолжать использовать канал, который может подключаться к любому администратору очередей.

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