队列管理器*上的DLQ是否必须是QM上的本地队列?

时间:2012-03-13 15:28:27

标签: ibm-mq

我们正在尝试将我们企业中的DLQ整合到一个Q(如果您愿意,则为Enterprise_DLQ)。我们在各种平台上混合使用QM - 大型机,各种Unix风格 - Linux,AIX,Solaris等,Windows,AS / 400 .... 我们的想法是将QM上的DLQ(在QM上设置DEADQ属性)配置为作为Cluster Q的ENTERPRISE_DLQ的DLQ.Enterprise中的所有QM都是Cluster的成员。然而,当我们测试它时,这种方法似乎不起作用。 我通过设置一个包含4个QM的简单集群来测试它。在其中一个QM上,将QRemote定义为不存在的QM和不存在的Q,但是有效的xmitq并在QM之间配置requsite SDR chl,如下所示:

QM_FR - Full_Repos QM1,QM2,QM3 - 集群成员

QM_FR托管向群集公布的ENTERPRISE_DLQ

在QM3上设置以下内容: QM3.QM1 - sdr到QM1,ql(QM1)使用xmitq,qr(qr.not_exist)rqmname(not_exist)rname(not_exist)xmitq(qm1),设置QM1触发 - 当msg到达QM1时启动QM3.QM1

在QM1上: QM3.QM1 - rcvr chl,ql(local_dlq),ql(qa.enterise_dlq),qr(qr.enterprise.dlq)

测试1: 将QM1上的deadq设置为ENTERPRISE_DLQ,在QM3上将QRg写入QR.NOT_EXIST 结果:Msg保持QM1,QM3.QM1正在重试,QM1错误日志抱怨无法MQOPEN Q - ENTERPRISE_DLQ !!

ql(qm1)curdepth(1)

测试2: 将QM1上的deadq设置为qr.enterprise.dlq,在QM3上将QRg写入QR.NOT_EXIST 结果:Msg保持QM1,QM3.QM1正在重试,QM1错误日志抱怨无法MQOPEN Q - qr.enterprise.dlq(全部大写)!!

ql(qm1)curdepth(2)

测试3: 将QM1上的deadq设置为qa.enterise_dlq,在QM3上将QRg写入QR.NOT_EXIST 结果:Msg保持QM1,QM3.QM1正在重试,QM1错误日志抱怨无法MQOPEN Q - qa.enterise_dlq(全部大写)!!

ql(qm1)curdepth(3)

测试4: 将QM1上的deadq设置为local_dlq,将QM3上的msg写入QR.NOT_EXIST 结果:Msg保持在QM1,QM3.QM1正在运行,QM3 ql(QM1)上的所有消息都在QM3上进入local_dlq。

ql(qm1)curdepth(0)

现在的问题是:看起来QM 上的DLQ必须是本地队列。这是正确的结论吗?如果没有,我怎样才能将所有DLQ消息转到上面的单个Q-Enterprise_DLQ?

一个明显的解决方案是在QM3上的local_dlq上定义一个触发器(并在其他QM上执行相同操作),这将触发msg并将其写入Cluster Q-ENTERPRISE_DLQ。但这涉及额外的移动部件 - 每个QM上的触发器,触发器监视器。最希望能够将群集Q / QRemote / QAlias配置为QM上的DLQ。想法/想法???

由于 -Ravi

1 个答案:

答案 0 :(得分:2)

根据文档here

  

除了以下内容之外,死信队列没有特殊要求:

     
      
  • 必须是本地队列
  •   
  • 其MAXMSGL(最大消息长度)属性必须使队列能够容纳队列管理器具有的最大消息   处理加上死信头的大小(MQDLH)
  •   

DLQ为QMgr提供了一种处理通道无法传递的消息的方法。如果DLQ不是本地的,那么信道的错误处理本身将取决于信道。这会带来一些建筑设计缺陷。

执行所需操作的指定方法是触发作业以将消息转发到远程队列。这样,只要消息到达DLQ,触发的作业就会启动并转发消息。如果您不想编写这样的程序,可以轻松地使用一些shell或Perl代码以及来自SupportPac MA01的Q程序。可取的是,用于从QMgr发送此类消息的信道将被设置为不使用DLQ。理想情况下,这些将存在于专用群集中,因此DLQ流量不会与应用流量混合。

另外,请注意,如果转换错误阻止发送消息,DLQ的其中一个功能是将消息移出XMitQ。将它们转发到中心位置会产生将它们放回集群XMitQ的效果。同样,如果目的地填满,这些消息也将位于发送qMgr的群集XMitQ上。如果它们在那里建立足够的数量,则完整的集群XMitQ将阻止所有集群通道工作。在那种情况下,您需要某种工具来让您有选择地删除或移出群集XMitQ中的消息,这将有点挑战。

考虑到所有这一切,这一要求似乎会带来比它解决的更多挑战。建议:最好在不进一步使用频道的情况下处理频道的错误处理 - 即本地。