为什么我的集群不支持 CLWLPRTY？
Why is my cluster not honouring CLWLPRTY?
我有以下设置：
- 集群中的四个 MQ 队列管理器（
QM1（完整回购）、QM2（完整回购）、QM3（部分回购）、QM4（部分回购））
- 所有集群 sender/receiver 通道具有相同的等级和优先级
- 每个队列管理器都有一个非集群别名队列（
ALIAS.TO.CLQ）
ALIAS.TO.CLQ有一个基础对象ALIAS.TO.FLOW，它是一个集群别名队列ALIAS.TO.FLOW 有一个基础对象 L.TO.FLOW，这是一个本地队列。- 四个队列管理器中的每一个都配置为
CLWLUSEQ(ANY)。
- 集群别名队列的
DEFBIND 为 NOT FIXED。消息由 IIB（MQ 输出节点）编写，我相信它尊重这一点 - 尽管我也使用 MQ Explorer 或 RFHUtil 看到相同的行为。
- 消息由 MQ 输出节点放置而不指定队列管理器名称
- 四个集群别名队列中的每一个都有不同的
CLWLPRTY，但相同的CLWLRANK。
此配置的目的是强制消息由同一本地队列接收，无论消息最初放入哪个队列管理器。如果该队列管理器不可用，则应使用第二高优先级，依此类推。
我发现的问题是，对于四个队列管理器中的三个，CLWLPRTY 被接受并且消息被路由到最高优先级的队列管理器。但是，在具有最高优先级的队列管理器上，消息被路由到第二高的优先级；而不是在具有最高优先级的同一个队列管理器上使用队列。
如果我更改具有第二高优先级的队列管理器，消息总是从具有最高优先级的队列管理器路由到那里 - 所以这不仅仅是巧合。如果两个队列实例共享最高优先级，它永远不会 select 与它在同一个队列管理器上的那个；它似乎总是更喜欢出去集群。
这是怎么回事，我怎样才能让它始终尊重优先级，无论消息放在哪里？我查看了 IBM 文档 (https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ref.con.doc/q082390_.html) 中的 "cluster workload management algorithm" 页面，但我看不出哪里出错了。
--更新--
我尝试以相同的格式创建一组新的队列，但只在一个集群队列管理器上 - 所以，ALIAS.TEST -> AL.TEST（集群但只有一个实例存在）-> L.TEST。当我输入 ALIAS.TEST 时，我收到一条错误消息：
An MQOPEN or MQPUT1 call was issued, specifying an alias queue as the target, but the BaseObjectName in the alias queue definition resolves to a queue that is not a local queue, or local definition of a remote queue. (AMQ4480)
An MQOPEN or MQPUT1 call was issued, specifying an alias queue as the target, but the BaseObjectName in the alias queue definition resolves to a queue that is not a local queue, or local definition of a remote queue. (AMQ4480)
Severity: 20 (Error)
Response: Correct the queue definitions.
但我可以毫无问题地放入 AL.TEST 队列。
--编辑--
好的，为什么会发生的答案出现在这里：https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.pro.doc/q003120_.html
An alias cannot directly resolve to another alias on the same queue manager.
那么我怎样才能得到我想要的行为呢？
基于以下每个 IIB 实例放入本地队列管理器的流程：
IIB1 -> QM1 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(4) CLWLUSEQ(ANY)
IIB2 -> QM2 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(3) CLWLUSEQ(ANY)
IIB3 -> QM3 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(2) CLWLUSEQ(ANY)
IIB4 -> QM4 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(1) CLWLUSEQ(ANY)
*假设所有 CLUSRCVR 通道上的 CLWLRANK、CLWLPRTY 和 NETPRTY 在所有四个队列管理器上都相同。
四个 IIB 实例中的任何一个 PUT 的消息将始终流向具有最高 CLWLPRTY 的可用队列。
出于多种原因，从集群工作负载管理算法的角度来看，队列实例可能不可用。我参考了这篇 post 末尾的知识中心，它提供了算法的详细解释。两个常见原因是：
队列管理器已关闭
队列是PUT(DISABLED)
每个 IIB 实例只会 GET 来自与 IIB 实例连接的同一队列管理器上的本地队列。在上面描述的设置中，这意味着在正常情况下，如果所有四个队列管理器都已启动，则只有连接到 QM1 的 IIB 实例会接收消息。
可在 IBM MQ v9.0 知识中心页面“Reference>Configuration reference>IBM MQ cluster commands>Workload balancing in clusters>The cluster workload management algorithm”中找到导致队列实例不可用的原因，我提供了可应用于您问题中描述的设置的那些：
The algorithm steps through the following rules to eliminate
destinations from the list of possible destinations.
If a queue or topic name is specified:
a. Queues that are not put enabled are eliminated as possible
destinations.
When choosing a queue, if the resulting set of queues contains the local instance of the queue, the local instance is typically used. The
local instance of the queue is used if one of these three conditions
are true:
For locally defined queues that are defined with CLWLUSEQ(ANY), or
which inherit that same setting from the queue manager, the following
points are true, within the wider set of conditions that apply:
a. The local queue is chosen, based on the status of the locally-defined CLUSRCVR channels in the same cluster as the queue.
This status is compared to the status of the CLUSSDR channels that
would take the message to remotely defined queues of the same name.
For example, there is one CLUSRCVR in the same cluster as the queue. That CLUSRCVR has STOPPING status, whereas the other queues of
the same name in the cluster have RUNNING or INACTIVE status.
In this case the remote channels will be chosen, and the local queue is not used.
b. The local queue is chosen based on the number of CLUSRCVR channels, in any comparison with CLUSSDR channels of the same status,
that would take the message to remotely defined queues of the same
name.
For example, there are four CLUSRCVR channels in the same cluster as the queue, and one CLUSSDR channel. All the channels have the same
status of either INACTIVE or RUNNING.
Therefore there are five channels to choose from, and two instances of the queue. Four fifths (80 percent) of the messages go to
the local queue.
If only remote instances of a queue or topic remain, resumed queue managers are chosen in preference to suspended ones.
If more than one remote instance of a queue or topic remains, all channels that are inactive or running are included. The state
constants are listed:
MQCHS_INACTIVE
MQCHS_RUNNING
If no remote instance of a queue or topic remains, all channels that are in binding, initializing, starting, or stopping state are
included. The state constants are listed:
MQCHS_BINDING
MQCHS_INITIALIZING
MQCHS_STARTING
MQCHS_STOPPING
If no remote instance of a queue or topic remains, all channels that are being tried again are included. The state constant is listed:
MQCHS_RETRYING
If no remote instance of a queue or topic remains, all channels in requesting, paused, or stopped state are included. The state constants
are listed:
MQCHS_REQUESTING
MQCHS_PAUSED
MQCHS_STOPPED
我有以下设置：
- 集群中的四个 MQ 队列管理器（
QM1（完整回购）、QM2（完整回购）、QM3（部分回购）、QM4（部分回购）） - 所有集群 sender/receiver 通道具有相同的等级和优先级
- 每个队列管理器都有一个非集群别名队列（
ALIAS.TO.CLQ） ALIAS.TO.CLQ有一个基础对象ALIAS.TO.FLOW，它是一个集群别名队列ALIAS.TO.FLOW有一个基础对象L.TO.FLOW，这是一个本地队列。- 四个队列管理器中的每一个都配置为
CLWLUSEQ(ANY)。 - 集群别名队列的
DEFBIND为NOT FIXED。消息由 IIB（MQ 输出节点）编写，我相信它尊重这一点 - 尽管我也使用 MQ Explorer 或 RFHUtil 看到相同的行为。 - 消息由 MQ 输出节点放置而不指定队列管理器名称
- 四个集群别名队列中的每一个都有不同的
CLWLPRTY，但相同的CLWLRANK。
此配置的目的是强制消息由同一本地队列接收，无论消息最初放入哪个队列管理器。如果该队列管理器不可用，则应使用第二高优先级，依此类推。
我发现的问题是，对于四个队列管理器中的三个，CLWLPRTY 被接受并且消息被路由到最高优先级的队列管理器。但是，在具有最高优先级的队列管理器上，消息被路由到第二高的优先级；而不是在具有最高优先级的同一个队列管理器上使用队列。
如果我更改具有第二高优先级的队列管理器，消息总是从具有最高优先级的队列管理器路由到那里 - 所以这不仅仅是巧合。如果两个队列实例共享最高优先级，它永远不会 select 与它在同一个队列管理器上的那个；它似乎总是更喜欢出去集群。
这是怎么回事，我怎样才能让它始终尊重优先级，无论消息放在哪里？我查看了 IBM 文档 (https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ref.con.doc/q082390_.html) 中的 "cluster workload management algorithm" 页面，但我看不出哪里出错了。
--更新--
我尝试以相同的格式创建一组新的队列，但只在一个集群队列管理器上 - 所以，ALIAS.TEST -> AL.TEST（集群但只有一个实例存在）-> L.TEST。当我输入 ALIAS.TEST 时，我收到一条错误消息：
An MQOPEN or MQPUT1 call was issued, specifying an alias queue as the target, but the BaseObjectName in the alias queue definition resolves to a queue that is not a local queue, or local definition of a remote queue. (AMQ4480) An MQOPEN or MQPUT1 call was issued, specifying an alias queue as the target, but the BaseObjectName in the alias queue definition resolves to a queue that is not a local queue, or local definition of a remote queue. (AMQ4480)
Severity: 20 (Error)
Response: Correct the queue definitions.
但我可以毫无问题地放入 AL.TEST 队列。
--编辑--
好的，为什么会发生的答案出现在这里：https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.pro.doc/q003120_.html
An alias cannot directly resolve to another alias on the same queue manager.
那么我怎样才能得到我想要的行为呢？
基于以下每个 IIB 实例放入本地队列管理器的流程：
IIB1 -> QM1 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(4) CLWLUSEQ(ANY)
IIB2 -> QM2 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(3) CLWLUSEQ(ANY)
IIB3 -> QM3 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(2) CLWLUSEQ(ANY)
IIB4 -> QM4 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(1) CLWLUSEQ(ANY)
*假设所有 CLUSRCVR 通道上的 CLWLRANK、CLWLPRTY 和 NETPRTY 在所有四个队列管理器上都相同。
四个 IIB 实例中的任何一个 PUT 的消息将始终流向具有最高 CLWLPRTY 的可用队列。
出于多种原因，从集群工作负载管理算法的角度来看，队列实例可能不可用。我参考了这篇 post 末尾的知识中心，它提供了算法的详细解释。两个常见原因是：
队列管理器已关闭
队列是
PUT(DISABLED)
每个 IIB 实例只会 GET 来自与 IIB 实例连接的同一队列管理器上的本地队列。在上面描述的设置中，这意味着在正常情况下，如果所有四个队列管理器都已启动，则只有连接到 QM1 的 IIB 实例会接收消息。
可在 IBM MQ v9.0 知识中心页面“Reference>Configuration reference>IBM MQ cluster commands>Workload balancing in clusters>The cluster workload management algorithm”中找到导致队列实例不可用的原因，我提供了可应用于您问题中描述的设置的那些：
The algorithm steps through the following rules to eliminate destinations from the list of possible destinations.
If a queue or topic name is specified:
a. Queues that are not put enabled are eliminated as possible destinations.
When choosing a queue, if the resulting set of queues contains the local instance of the queue, the local instance is typically used. The local instance of the queue is used if one of these three conditions are true:
For locally defined queues that are defined with CLWLUSEQ(ANY), or which inherit that same setting from the queue manager, the following points are true, within the wider set of conditions that apply:
a. The local queue is chosen, based on the status of the locally-defined CLUSRCVR channels in the same cluster as the queue. This status is compared to the status of the CLUSSDR channels that would take the message to remotely defined queues of the same name.
For example, there is one CLUSRCVR in the same cluster as the queue. That CLUSRCVR has STOPPING status, whereas the other queues of the same name in the cluster have RUNNING or INACTIVE status.
In this case the remote channels will be chosen, and the local queue is not used.
b. The local queue is chosen based on the number of CLUSRCVR channels, in any comparison with CLUSSDR channels of the same status, that would take the message to remotely defined queues of the same name.
For example, there are four CLUSRCVR channels in the same cluster as the queue, and one CLUSSDR channel. All the channels have the same status of either INACTIVE or RUNNING.
Therefore there are five channels to choose from, and two instances of the queue. Four fifths (80 percent) of the messages go to the local queue.
If only remote instances of a queue or topic remain, resumed queue managers are chosen in preference to suspended ones.
If more than one remote instance of a queue or topic remains, all channels that are inactive or running are included. The state constants are listed:
MQCHS_INACTIVE
MQCHS_RUNNINGIf no remote instance of a queue or topic remains, all channels that are in binding, initializing, starting, or stopping state are included. The state constants are listed:
MQCHS_BINDING
MQCHS_INITIALIZING
MQCHS_STARTING
MQCHS_STOPPINGIf no remote instance of a queue or topic remains, all channels that are being tried again are included. The state constant is listed:
MQCHS_RETRYINGIf no remote instance of a queue or topic remains, all channels in requesting, paused, or stopped state are included. The state constants are listed:
MQCHS_REQUESTING
MQCHS_PAUSED
MQCHS_STOPPED