Implement a connection between my application (Spring integration) with IBM-MQ - High Availability

1
votes

I am trying to implement a connection between my application (Spring integration) with IBM-MQ, I did see the question spring-integration-support-for-clustered-high-availability-ibm-mq-manager, but in my case each host has different "queueManager" and "channels", it means I will have must have a configuration like follows but, the queueManager and channels properties support a String not a list values:

<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>
1
spring-integrationibm-mqhigh-availability

1 Answers

1
votes

The simplest thing would be to define a channel with the same name on both hosts and let the client try host1 first and then host2 using connectionNameList. In this setup it would always prefer host1. You would need to specify a queueManager that is blank so that the client will accept the queue manager it connects to. Example follows:

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

Another option that was pointed out in a comment from Morag on the other post you linked to is to use a CCDT (Client channel definition table).

See Using a client channel definition table with IBM WebSphere MQ classes for JMS. The property name is CCDTURL

The CCDT can have multiple CLNTCONN channel entries with different channel names all having the same QMNAME, this is called a Queue Manager Group, you would then specify the queueManager property as *QMNAME, this will allow the app to connect to which ever queue manager you are directed to with out regard to the actual queue manager name. There are other parameters of the CLNTCONN listed at the bottom of the link I provided that can help you to control if one queue manager is preferred over the other(s) as well as which queue manager to connect to if a reconnect is required.