java - 每个主机/端口是否允许多个队列管理器？

Question

设置 MQQueueConnectionFactory 时我们将其初始化如下:

MQQueueConnectionFactory factory = new MQQueueConnectionFactory();

factory.setQueueManager(queueManager);

factory.setTransportType(CommonConstants.WMQ_CM_CLIENT);
factory.setHostName(host);
factory.setPort(port);
factory.setChannel(channel);

特别是我们设置了队列管理器的名称。从这个模式看来，队列管理器名称对于完全识别队列管理器是必要的。人们可能会得出结论，在同一主机和端口上，可能会有不同的队列管理器进行监听。这可能吗？

但是，当设置 the connection name list要指定重新连接目标，不需要队列管理器名称:

public void setConnectionNameList(java.lang.String hosts) throws javax.jms.JMSException

Specifies the hosts to which the client will attempt to reconnect to after its connection is broken. The connection name list is a comma seperated list of host/ip port pairs. eg. 127.0.0.1(1414),host2.example.com(1400) The default setting of this property is 'localhost(1414)' A null, or empty string is taken to mean localhost(1414)

当设置 client reconnect options在这种情况下，两个选项似乎很重要:

• WMQ_CLIENT_RECONNECT - Reconnect to the any of the queue managers specified in the connection name list
• WMQ_CLIENT_RECONNECT_Q_MGR - Reconnect to the same queue manager we were originally connected to. This will throw MQRC_RECONNECT_QMID_MISMATCH if the queue manager it tries to connect to (specified in the connection name list) has a different QMID to the queue manager originally connected to.

这些文档不清楚是否可以在同一主机/端口后面使用多个队列管理器。将此与 Oracle 相比，其中多个服务可以由同一个监听器提供服务。

我们有两个队列管理器监听具有不同名称的不同主机/端口。我们希望将这些队列管理器之一用作连接名称列表中的故障转移管理器。问题是:队列管理器是否仅由主机和端口唯一标识？

Answer 1

这个问题有很多要解开的地方，所以让我们一次一个项目。

只能有一个监听器绑定(bind)到特定端口和接口(interface)。因此，如果监听器是混杂的(监听所有接口(interface))，则每个端口只有一个。如果主机有多个接口(interface)，则可以在每个接口(interface)上的同一端口上绑定(bind)单独的监听器。由于监听器是队列管理器的子进程，这意味着只有一个 QMgr 可以监听给定的 address(port)。组合。

QMgr 名称不需要出现在 QMgr 接收到的连接请求中。如果 QMgr 名称为空，则与连接请求所针对的任何 QMgr 的连接都会成功，前提是 QMgr 不会因密码错误、证书验证或其他错误而拒绝它。但是，如果 QMgr 名称在连接请求中，它 必须与尝试连接的 QMgr 的名称相匹配。

连接名称列表(更准确地说是 CONNAME)是 address(port) 的逗号分隔列表有资格接收所请求的连接的组合。

多实例 QMgrs 有两个地址和一个端口。它们只在一个地址上处于 Activity 状态，指向它们的 channel 必须具有两个地址才能可靠地连接。但是，它不必具有 QMgr 名称。

但是还有另一种类型的 HA，其中有多个等效的 QMgrs，每个具有不同的名称，客户端可以连接到这些 QMgrs。当客户从记录系统请求信息但其本身不是记录系统时尤其如此。这样的客户端不需要监听众所周知的队列。相反，它连接到任何一个客户端连接 QMgrs 层，创建一个动态回复队列，并将请求发送到记录系统，该系统在 MQ 网络某处的集群队列上监听。在这种情况下，客户端没有指定 QMgr 名称，因此可以利用 MQ 接受它连接到的任何 QMgr 的行为。

最后，MQ 早就有客户端 channel 定义表或 CCDT 文件。在我们拥有多实例 CONNAME 之前CCDT 提供了连接到多个 QMgr 中的任何一个的能力。 MQ Admin 不是在 CCDT 中放置 QMgr 名称，而是放置符号名称。例如，如果有 3 个 QMgr 用于工资核算处理，则其 CCDT 条目中的 QMgr 名称可能是 PAY01、PAY02 和 PAY03，它们都不匹配实际的 QMgr 名称。每一个都有一个 address(port)指向三个 QMgr 之一。然后开发人员指定一个 QMgr 名称 *PAY并且 MQ 客户端将在前 3 个字符匹配“PAY”的所有 CCDT 条目中进行选择。使用此选项和其他一些选项，可以让 MQ 客户端驱动器重新连接，但让 MQ 客户端 stub 封装是否在目标之间循环、重试最后连接的地址等逻辑。

From this pattern it seems that the queue manager name is necessary to fully identify the queue manager. One might concluded that on the same host and port a different queue manager might listen. Is this possible?

不。

We have two queue managers listening on different hosts/ports which have different names. We want to use one of these queue managers as failover manager in the connection name list. The question is: is the queue manager uniquely identified by host and port only?

确保请求中的 QMgr 名称为空并指定 address(port) CONNAME 中的组合你应该很高兴。

请参阅:Role of the client channel definition table ，尤其是在 Queue manager groups in the CCDT 部分.关于 Examples of channel weighting and affinity 的部分在这里也很有帮助。

最后，请确保您使用的是现代客户端。由于 MQ 客户端可以连接到任何前向或后级 QMgr，因此可以在 v9.0 客户端上进行开发并连接到 v7.1 QMgr。当然，所提供的功能是基于最低版本的客户端或 QMgr，因此您不会获得具有 v9.0 客户端和古老 QMgr 的 JMS 1.2 功能。但是，您确实会在以后的客户端版本中获得所有性能改进和错误修复。如果您不是最新的客户端(或 JEE 服务器支持的最新客户端)，请在以下位置下载一个:

SupportPac MQC75

SupportPac MQC8

SupportPac MQC9