我有一个如下所示的队列定义:
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)
以下是我的问题:
INITQ
上配置它,则与队列关联的进程将不会运行。这是对的吗?INITQ(TRIG.INITQ)
上运行。我们必须在INITQ
上运行触发器监视器吗?runmqchi
上有system.channel.initiation.queue
,因此启动了通道。那么runmqtrm
和runmqchi
功能类似吗?INITQ
。那么,我们怎么知道我们收到什么样的警报呢?答案 0 :(得分:6)
好的,我们一次拿这些。
我想,触发器将处理所有触发器消息 监控脚本。如果我们不在INITQ上配置它,请处理哪个 与队列关联不会运行。这是对的吗?
如果我理解你在问什么,那么如果在启动队列中没有任何内容侦听,那么是否会触发该进程。那是正确的。应用程序队列必须设置TRIGGER
并指定INITQ
值。指定的启动队列必须具有打开的输入句柄,以便MQ格式化并放置触发器消息。
如果是,我们的触发器监视器未在INITQ:TRIG.INITQ上运行。 我们还必须在INITQ上运行触发器监控吗?
是。队列的INITQ
是QMgr放置任何触发器消息的位置。 QMgr不会放置触发器消息,除非在该启动队列上有一个打开的输入句柄,并且该句柄最好来自触发器监视器它不起作用。
当我们配置传输队列时,为了触发,我们 定义了触发器数据和过程定义。虽然我们 没有在启动队列,通道上配置触发器监视器 因为我们在INITQ上运行了runmqchi而开始运行。所以runmqtrm和runmqchi 功能类似?
与触发器监视器相比,通道启动器对于草率配置更加宽容。从通道定义中可以很容易地计算出它使用的传输队列。因此MQ表明,如果管理员定义了XMITQ
类型的队列,则将其设置为TRIGGER
,那么意图必须是启动一个通道。然后它从通道defs向后工作以发现哪个通道与该队列相关联。
但runmqtrm
没有这样安全的假设。您必须将队列的INITQ
和PROCESS
属性中的点连接到触发监视器,监听指定的INITQ
并启动相关进程,正确读取触发器消息,然后按预期处理队列。
在这里,我们触发了每条消息和队列深度 事件。在这两种情况下,触发器消息都将被置于同一个位置 INITQ。那么,我们如何知道我们收到了什么样的警报?
这是两件不同的事情。只能在队列中指定一种类型的触发,它是FIRST
,DEPTH
或EVERY
中的一种。您还可以指定当队列深度超过某个阈值时,QMgr将向事件队列(而不是启动队列)发出事件消息。
这两件事情是相关但完全不同的仪器类型。触发仪器旨在在特定条件下启动过程。队列深度事件旨在将实时操作信息提供给监听事件队列的监视代理程序。
有关触发的更多信息,包括围绕有用应用程序构建的小型教程以及实现它的示例脚本,请参阅Mission:Messaging: Easing administration and debugging with circular queues