【问题标题】:Triggering for events事件触发
【发布时间】:2015-07-21 15:28:22
【问题描述】:

我有一个如下的队列定义:

DEFINE QLOCAL(TRIG.QLOCAL) + 
       DESCR('Example Queue for Triggering') + 
       DEFPRTY(0) + 
       DEFSOPT(SHARED) + 
       GET(ENABLED) + 
       MAXDEPTH(5000) + 
       MAXMSGL(4194304) + 
       MSGDLVSQ(PRIORITY) + 
       PUT(ENABLED) + 
       QDEPTHHI(80) +
       QDPHIEV(ENABLED)+
       RETINTVL(999999999) + 
       TRIGTYPE(EVERY) + 
       PROCESS(TRIG.PROCESS) + 
       INITQ(TRIG.INITQ) + 
       USAGE(NORMAL) + 
       REPLACE 

我已经定义了如下流程:

DEFINE PROCESS(TRIG.PROCESS) APPLTYPE(UNIX) +
       APPLICID(/appn/sy31/QdepthHiAlert.sh) +
       ENVRDATA(' ') +
       USERDATA(' ') 
       DESCR('PROCESS FOR TESTING QDEPTH HIGH EVENT') +
       REPLACE

我有一个触发器监视器作为服务运行,如下所示:

   SERVICE(TRIGGER_MONITOR)                STATUS(RUNNING)
   PID(49610840)                           SERVTYPE(SERVER)
   CONTROL(QMGR)                           STARTCMD(/usr/bin/runmqtrm)
   STARTARG(-m PACOHB20 -q SYSTEM.DEFAULT.INITIATION.QUEUE)

这是我的问题:

  1. 我想,所有的触发消息都会被触发监控脚本处理。如果我们不在INITQ 上配置它,与队列关联的进程将不会运行。对吗?
  2. 如果是,我们的触发器监视器没有在队列的INITQ(TRIG.INITQ) 上运行。我们也必须在INITQ 上运行触发器监视器吗?
  3. 当我们为触发配置传输队列时,我们已经定义了触发数据和流程定义。尽管我们没有在启动队列上配置触发器监视器,但通道已启动,因为我们在 system.channel.initiation.queue 上有 runmqchi。那么runmqtrmrunmqchi 的功能类似吗?
  4. 在这里,我们触发了每条消息和队列深度高事件。在这两种情况下,触发消息将被放置到相同的INITQ。那么,我们如何知道我们收到了什么样的警报呢?

【问题讨论】:

    标签: ibm-mq


    【解决方案1】:

    好的,让我们一次拿这些。

    我想,所有的触发消息都会被触发器处理 监控脚本。如果我们不在 INITQ 上配置它,则处理 与队列相关联的将不会运行。对吗?

    如果我理解您的要求,那么如果启动队列上没有任何内容,是否会触发该进程。那是对的。应用程序队列必须设置TRIGGER 并指定INITQ 值。指定的启动队列必须具有打开的输入句柄,以便 MQ 格式化和放置触发消息。

    如果是,我们的触发器监视器没有在 INITQ 上运行:TRIG.INITQ。 我们是否也必须在 INITQ 上运行触发器监控?

    是的。队列的INITQ 是QMgr 放置任何触发消息的地方。 QMgr 不会放置触发消息除非该启动队列上有一个打开的输入句柄,并且该句柄最好来自触发器监视器,否则它将不起作用。

    当我们配置传输队列时,为了触发,我们 已经定义了触发数据和流程定义。虽然我们 未在启动队列、通道上配置触发器监视器 自从我们在 INITQ 上运行了 runmqchi 后就运行了。所以 runmqtrm 和 runmqchi 功能类似?

    通道启动器比触发器监视器更能容忍草率的配置。从通道定义中很容易确定它使用哪个传输队列。因此 MQ 认为,如果管理员定义了一个 XMITQ 类型的队列,将其设置为 TRIGGER,那么其目的必须是启动一个通道。然后它从通道定义向后工作以发现 哪个 通道与该队列相关联。

    但是runmqtrm 没有这样的安全假设。您必须将队列的INITQPROCESS 属性中的点连接到侦听指定INITQ 的触发器监视器,并启动相关进程,正确读取触发器消息,然后处理按预期排队。

    在这里,我们触发了每条消息和高队列深度 事件。在这两种情况下,触发消息将被放置到相同的 初始化。那么,我们如何知道我们收到了什么样的警报呢?

    这是两个不同的东西。在队列上只能指定一种触发类型,它是FIRSTDEPTHEVERY 之一。您还可以指定当队列深度超过某个阈值时,QMgr 将向事件队列(而不是启动队列)发出事件消息。

    这两件事是相关但完全不同类型的仪器。触发仪表设计用于在特定条件下启动过程。队列深度事件旨在向监听事件队列的监控代理提供实时操作信息。


    有关触发的更多信息,包括围绕有用应用程序构建的迷你教程和实现它的示例脚本,请参阅Mission:Messaging: Easing administration and debugging with circular queues

    【讨论】:

    • 感谢您的详细解释。读完这篇文章后,我又想到了两个问题。 1.runmqchi向后工作?每个触发消息都将具有导致触发的队列的名称,并且需要在其有效负载中调用进程,对吗?如果是这样,为什么它需要回溯呢? 2. 对于触发类型为DEPTH 的队列。当CURDEPTH 跨越MAXDEPTH 的80% 时,会产生queue_depth_high 事件。如果队列已满,它会生成queue_depth_highqueue_full 事件吗?如果它产生queue_full事件,我们如何区分high_depth和full事件?
    • "我们如何区分 high_depth 和 full 事件?"对于 QDepth High 事件,MQCFH 中的原因代码将是 2224,对于 QFull 事件,将是 2053。请看:www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/…
    • 通道启动器不再需要定义进程,也不再需要队列的PROCESS 属性中的通道名称。当 XmitQ 被触发时,runmqchi 必须通过将通道中指定的 XMITQ 值与被触发的队列的名称相匹配来确定要启动哪个通道。然而,IBM 让runmqchi 这样做比对客户定义流程提出严格要求更容易,这样他们获得的 PMR 更少。
    • "感谢您的详细解释。"详细程度反映了这是一个由 4 部分组成的问题。我别无选择。 ;-)(但不客气!)
    猜你喜欢
    • 1970-01-01
    • 2020-09-24
    • 2015-07-08
    • 2010-10-27
    • 1970-01-01
    • 1970-01-01
    • 2014-09-18
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多