Question

I am trying to use MQQueueManager with multiple instances
In .net, we have IBM MQ jar provided with MQC.CONNECTION_NAME_PROPERTY

    ConnectionName = "fred.mq.com(2344),nick.mq.com(3746),tom.mq.com(4288)";
    Hashtable Properties-new Hashtable();
    properties.Add(MQC.CONNECTION_NAME_PROPERTY,ConnectionName);
    MQQueueManager qmgr=new MQQueue Manager("qmgrname",properties);

Source: http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/index.jsp?topic=%2Fcom.ibm.mq.doc%2Fun11010_.htm

But, a similar thing where I can use the connection name list on MQQueueManager, using java is not provided.

Could you please help me here?
I am using 7.0.1.6 jars

Answer 1

Please refer to Using a client channel definition table with WebSphere MQ classes for Java in the Infocenter. I’ve linked to the V7.0 Infocenter since you mentioned that’s the version you are using but it works the same in later versions.

Before there were Multi-Instance QMgrs and the corresponding multi-instance CONNAME attributes in the channel definitions, there was the Client Channel Definition Table or CCDT as it is more commonly known. The CCDT contains the CLNTCONN definitions for any number of channels to one or more QMgrs. When multiple entries have the same value in the QMName field, they are treated as a group. (Note, the QMName in the CCDT does not need to match the actual QMgr name. That would force you to use non-unique QMgr names which is not a good practice. It is just an index into the CCDT to identify groups of channels.)

To better understand the CCDT, please read the topics under Connecting WebSphere MQ client applications to queue managers in the Infocenter and in particular, Examples of channel weighting and affinity, Role of the client channel definition table and Examples of MQCONN calls. (Access these from the Table of Contents on the left. At the very top right of the frame is a button that will sinc the Table of Contents to whatever page you are on if you get lost.)

The one “gotcha” with CCDT is that each channel name within it must be unique. This differs from the Multi-Instance CONNAME which looks for the exact same channel at different IP addresses. This is because the CCDT file is maintained using MQSC commands on the QMgr. Within the namespaces managed by the queue manager, all object names must be unique. When defining channels on a QMgr, each channel must have a unique name. In the case of the CCDT the entries are defined using CLNTCONN channels. Although these point to SVRCONN channels defined on other QMgrs, because all the CLNTCONN channels are defined in the same namespace, they must be unique.

To illustrate this further consider provisioning an app called PAYROLL. You might construct the channel names based on the app name combined with the QMgr name. This results in a channel that describes a from–>to relationship reading left to right. For example, to define the CCDT for three QMgrs you would have:

* On any QMgr
DEF CHL(PAYROLL.QMGR1) CHLTYPE(CLNTCONN) QMNAME(PAY) CONNAME("qm1host(1414)")
DEF CHL(PAYROLL.QMGR2) CHLTYPE(CLNTCONN) QMNAME(PAY) CONNAME("qm2host(2414)")
DEF CHL(PAYROLL.QMGR3) CHLTYPE(CLNTCONN) QMNAME(PAY) CONNAME("qm3host(3414)")

*On QMgr1
DEF CHL(PAYROLL.QMGR1) CHLTYPE(SVRCONN) 

*On QMgr2
DEF CHL(PAYROLL.QMGR2) CHLTYPE(SVRCONN) 

*On QMgr3
DEF CHL(PAYROLL.QMGR3) CHLTYPE(SVRCONN) 

Then the app specifies the QMgr name as *PAY and the WMQ client code chooses among the three entries. Additional parameters are available for weighting the entries and retry order, which you will see in the docs.

Note: the examples shown are stripped down to the essential elements that illustrate the concept. The SVRCONN entries for a production implementation would include an MCAUSER and/or a channel exit, possibly SSL parms and, on V7.1 or later, some CHLAUTH rules.