MQQueueManager中的多个实例

我正在尝试将MQQueueManager与多个实例一起使用
在.net中,我们提供了MQC.CONNECTION_NAME_PROPERTY提供的IBM MQ jar

    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);

资料来源：http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/index.jsp?topic=%2Fcom.ibm.mq.doc%2Fun11010_.htm

但是,类似的东西,我可以使用MQQueueManager上的连接名称列表,不提供使用java.

你能帮帮我吗？
我使用的是7.0.1.6罐子

解决方法:

请参考信息中心的Using a client channel definition table with WebSphere MQ classes for Java.我已经链接到V7.0信息中心,因为您提到的是您正在使用的版本,但它在以后的版本中的工作方式相同.

在通道定义中存在多实例QMgrs和相应的多实例CONNAME属性之前,存在客户端通道定义表或CCDT,因为它更为人所知. CCDT包含对一个或多个QMgrs的任意数量通道的CLNTCONN定义.当多个条目在QMName字段中具有相同的值时,它们将被视为一个组. (注意,CCDT中的QMName不需要匹配实际的QMgr名称.这将迫使您使用非唯一的QMgr名称,这不是一个好习惯.它只是CCDT的一个索引,用于识别通道组. )

为了更好地理解CCDT,请阅读信息中心Connecting WebSphere MQ client applications to queue managers下的主题,特别是信道加权和亲和性的示例,客户端信道定义表的角色和MQCONN呼叫的示例. (从左侧的目录中访问这些内容.在框架的最右上方是一个按钮,如果你迷路,它将把目录放到你所在的任何页面上.)

CCDT的一个“问题”是其中的每个通道名称必须是唯一的.这与多实例CONNAME不同,后者在不同的IP地址查找完全相同的通道.这是因为使用QMgr上的MQSC命令维护CCDT文件.在由队列管理器管理的名称空间内,所有对象名称必须是唯一的.在QMgr上定义通道时,每个通道必须具有唯一的名称.在CCDT的情况下,使用CLNTCONN通道定义条目.虽然这些指向其他QMgrs上定义的SVRCONN通道,但由于所有CLNTCONN通道都在同一名称空间中定义,因此它们必须是唯一的.

为了说明这一点,请进一步考虑配置一个名为PAYROLL的应用程序.您可以根据应用程序名称和QMgr名称构建通道名称.这导致描述从左到右的从 – >到关系读数的通道.例如,要为三个QMgrs定义CCDT,您将拥有：

* 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) 

然后,应用程序将QMgr名称指定为* PAY,WMQ客户端代码在三个条目中进行选择.其他参数可用于加权条目和重试顺序,您将在文档中看到这些参数.

注意：显示的示例被分解为说明概念的基本元素.生产实现的SVRCONN条目包括MCAUSER和/或通道出口,可能包括SSL parms,以及V7.1或更高版本的一些CHLAUTH规则.

标签：java,ibm-mq,multiple-instances
来源： https://codeday.me/bug/20190629/1331117.html