Реализовать соединение между моим приложением (интеграция Spring) с IBM-MQ - High Availability

Я пытаюсь реализовать соединение между моим приложением (интеграция Spring) с IBM-MQ, я видел вопрос spring-integration-support-for-clustered-high-availability-ibm-mq-manager, но в моем случае каждый хост имеет разные "queueManager" и "каналы ", это означает, что у меня должна быть конфигурация, подобная следующей, но свойства очереди и каналов поддерживают строку, а не значения списка:

<bean id="connectionFactory" class="com.ibm.mq.jms.MQQueueConnectionFactory">
        <property name="connectionNameList" value="host1(6464),host1(6464)" />
        <property name="clientReconnectTimeout" value="15000" />
        <property name="transportType" value="1" />
        <property name="queueManager" value="QM1, QM1," />
        <property name="channel" value="channel1,channel1"/> 
</bean>

high-availability ibm-mq spring-integration
person Lixania    schedule 19.01.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Проще всего было бы определить канал с одинаковым именем на обоих хостах и ​​позволить клиенту сначала попробовать host1, а затем host2, используя connectionNameList. В этой настройке он всегда будет предпочитать host1. Вам нужно будет указать queueManager пустым, чтобы клиент принимал диспетчер очередей, к которому он подключается. Пример следующий:

    <property name="queueManager" value="" />

Другой вариант, который был указан в комментарии Мораг к другому сообщению, на которое вы ссылались, — это использование CCDT (таблица определения клиентского канала).

См. раздел Использование определения клиентского канала. таблица с классами IBM WebSphere MQ для JMS. Имя свойства: CCDTURL

CCDT может иметь несколько CLNTCONN записей каналов с разными именами каналов, имеющих одно и то же QMNAME, это называется Группа диспетчеров очередей, затем укажите свойство queueManager как *QMNAME, это позволит приложению подключаться к тому диспетчеру очередей, к которому вы направляетесь. независимо от фактического имени администратора очередей. Существуют и другие параметры CLNTCONN, перечисленные в нижней части предоставленной мной ссылки, которые могут помочь вам контролировать, является ли один диспетчер очередей предпочтительным по сравнению с другим (-ами), а также к какому диспетчеру очередей подключаться, если требуется повторное подключение.

person JoshMc    schedule 19.01.2017
comment
Джош Мак, большое спасибо. Я попробовал первый вариант, и он работает очень успешно - person Lixania; 20.01.2017