【问题标题】:Overlapping MQ Cluster and reply message delivery with IBM MQ使用 IBM MQ 重叠 MQ 集群和回复消息传递
【发布时间】:2017-08-25 08:01:44
【问题描述】:

我有两个集群CLUSMESCLUSHUBS。每个集群有两个队列管理器。

集群 CLUSMES 具有 QMGRS:QMGR1AQMGR1B
集群 CLUSHUBS 具有 QMGRS:QMGR3AQMGR3B

有一个网关 QMGR:QMGR2,它形成了重叠,是每个 MQ 集群中的部分存储库。

请求消息通过QMGR2QMGR1A/B 发送到QMGR3A/BQMGR2 作为集群负载平衡到QMGR3A/B(这工作正常),并且预计会回复发送 QMGR。

所有渠道连接都已到位且功能齐全。问题是如何从消息的来源返回消息。回复 QMGR 连接到 QMGR3A/B 并发出 put。我会得到一个 REMOTE_QMGR not found (MQRC 2087) 或一个 MQ Object not found (MQRC 2085),这取决于我的配置方式。消息的消息头正确包含ReplytoQueueReplyToQMgr。我想让回复应用程序只发出一个 put 并将其传递到 CLUSMES 中的正确队列,但这被证明是非常困难的。我在 GateWay Qmgr 上玩过 Remote QMGR Alias 和 QAlias:QMGR2,但没有运气。必须有一个简单的技巧,并且有很多示例,但是我无法成功实现。一个明确的例子来说明我的返回路径应该是最有帮助的。请记住,ReplyToQMgr 位于MQMD 中,并且需要从中进行解决。我需要在QMGR2 级别进行解析,其中两个集群都是已知的。对具体的完整建议表示赞赏。

QMGR1A/B 上的 MQ 定义,其中需要回复:

DEFINE QLOCAL('SERVER.REPLYQ') CLUSTER('CLUSMES') 

关于 QMGR2(消息希望的网关)

DEFINE NAMELIST(CLUSTEST) NAMES(CLUSMES,CLUSHUBS)

DEFINE QALIAS(SERVER.ALIAS.REPLYQ) TARGQ(SERVER.REPLYQ) CLUSTER(CLUSTEST) DEFBIND(NOTFIXED)

DEFINE QREMOTE(QMGR1A) RNAME(' ') RQMNAME(QMGR1A) XMITQ('') CLUSTER(CLUSHUBS)
DEFINE QREMOTE(QMGR1B) RNAME(' ') RQMNAME(QMGR1B) XMITQ('') CLUSTER(CLUSHUBS)

在 MQMGR3A/B QALIAS(SERVER.ALIAS.REPLYQ) 集群队列上。网关 QMGR 无法解析 baseQ:mqrc_unknown_alias_base_q 2082

这是尝试使用集群解决问题时的配置。

【问题讨论】:

  • 上面很少有问题。 1. 引用NAMELIST 的方式是CLUSNL 属性而不是CLUSTER 属性。 2.我不相信你可以在一台服务器上拥有一个集群QALIAS,如果你打算从另一个集群队列中放入QALIAS,那么它可以解析为另一台服务器上的集群QLOCAL经理,但我必须对此进行测试。您能否指定请求应用程序放入ReplyToQueueReplyToQmgr 的值,如果回复应用程序使用相同的值,请注意回复应用程序指定的队列名称和队列管理器名称?
  • 如果请求应用程序在ReplyToQueue 中指定SERVER.REPLYQ 和在ReplyToQmgr 中指定QMGR1A,则您不需要QALIAS(SERVER.ALIAS.REPLYQ) 上的QALIAS(SERVER.ALIAS.REPLYQ) 对象,只需@987654359 @ 目的。 (将 1A 替换为上面的 2A 以获取第二次请求 qmgr)。
  • 如果回复应用程序没有使用ReplyToQueueReplyToQmgr 中指定的值,而是硬编码单个值,例如SERVER.ALIAS.REPLYQ 作为它发送回复的队列,那么您将拥有无法使用 MQ 功能将它们路由回正确的请求队列管理器。

标签: ibm-mq


【解决方案1】:

当应用程序发送请求消息时,它将指定 QMGR1AQMGR1BReplytoQueue 中的 ReplyToQMgr,并带有出现在 QMGR1AQMGR1B 上的队列名称,即回复队列不需要集群。

在网关队列管理器QMGR2 上,您将定义以下对象:

DEFINE QREMOTE(QMGR1A) RNAME('') RQMNAME(QMGR1A) XMITQ('') CLUSTER(CLUSHUBS)
DEFINE QREMOTE(QMGR1B) RNAME('') RQMNAME(QMGR1B) XMITQ('') CLUSTER(CLUSHUBS)

这将允许集群CLUSHUBS 中的任何队列管理器通过网关队列管理器QMGR2 将回复消息路由回QMGR1AQMGR1B


如果您想限制QMGR1AQMGR1B 上的队列,CLUSHUBS 集群中的队列管理器可以提供给您,您需要采取不同的方法。让我知道这是否是您需要的,我会通过一些建议更新我的答案。

【讨论】:

  • 为此,回复应用程序是否需要在 MQOD 消息头中指定 ReplyToQMGR?这将意味着应尽可能避免的应用程序更改。有其他方法吗?
  • 如果你的意思是请求的应用程序,留空,你的应用程序连接的qmgr将被填写。
  • 放置回复消息的服务器/应用程序将其放置到它所连接的默认 QMGR。您建议的解决方案暗示,应用程序需要向 REPLYToQmgr 发出 PUT,这将在 QMGR2 上定义 QALIAS。实际情况是,当应用程序向连接的 QMGR 发出 put 时,如何跨集群路由该消息。我有一个 QREMOTE QMGR Alias 定义为 QMGR2 集群到 CLUSMES,但它只提供循环样式并忽略真正的目的地。目前无法更改应用程序。
  • @SteveO 回复应用程序可以连接到默认 QMGR(在您的示例中为 QMGR3AQMGR3B)。当它放置消息时,它将基本队列管理器名称设置为ReplyToQMgr 中的名称(在这种情况下为QMGR1AQMGR1B),并将队列设置为ReplyToQueue 中的名称。默认队列管理器将处理通过CLUSHUBS 集群将其发送到 QMGR2,然后将其路由到正确的目标队列管理器。
  • @SteveO 请注意我提到的在QMGR2 上定义的两个对象是QREMOTE QMGR 别名,其中填写了RQMNAME。因为填写了RQMNAME,它不会轮询消息。如果您将 RQMNAME 留空,则仅当回复队列是集群的并且正如我所提到的它不需要集群时,消息才会轮询。
猜你喜欢
  • 2015-01-09
  • 1970-01-01
  • 2022-11-08
  • 1970-01-01
  • 2021-08-02
  • 1970-01-01
  • 1970-01-01
  • 2022-09-29
  • 2016-09-26
相关资源
最近更新 更多