From: "Heggie, Peter" <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Design Review - custom trigger monitor vs triggered program
Date: Tue, 29 Jul 2003 13:01:11 -0400
Hi Phil.. I'm buried in ERP implementation.
Thanks for reply - Actually the program does close the application queue
after it gets a message, so it behaves nicely but does more opens and
closes. The actual usage is light, about 100 a day (initially). The
program is not multi-threaded, but the design was to call for more
trigger monitors (to monitor other initiation queues..). The
recommendation was to set the application queue triggering to EVERY, but
I think FIRST would be better.
And Stefan, thank you also, I agree that triggering while already
triggered does not make sense, and somehow that must be a waste of
resources. In the past I have used the 'regular' triggering (ON FIRST).
Peter Heggie
(315) 428 - 3193
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 12:17 PM
To: [EMAIL PROTECTED]
Subject: Re: Design Review - custom trigger monitor vs triggered program
Hi Pete ! Long time...
After the program processes the Queue named in MQTMC2, does it close the
queue ? If not, then MQ will not issue a new trigger message. Is the
program multi-threaded? if not, then you're causing a bottle neck for
other trigger messages for other queues.
It might be more efficient since MQ doesn't have to load a program to
process the queues, but depends upon how frequently it gets scheduled.
I assume it's TRIGGER FIRST.
Phil
"Heggie, Peter"
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
NGRID.COM> cc:
Sent by: MQSeries Subject: Design Review -
custom trigger monitor vs triggered program
List
<[EMAIL PROTECTED]
n.AC.AT>
07/29/2003 11:16
AM
Please respond to
MQSeries List
Hello all - would appreciate your responses on this one.
We have someone who wants to use a custom trigger monitor to both read
the init queue message and process the application queue message. It
would be a long running process, on AIX, that waits forever (loops) on
the init queue. When a message arrives there (trigger message), it
extracts the queue name from the MQTMC2 and then opens the application
queue and processes the message. Then it goes back into the loop.
Setup - A trigger monitor is started at MQ startup time, pointing to a
specific init queue. The first message coming into the application queue
triggers normally - MQ writes a trigger message to the init queue and
the native MQ trigger monitor starts program XYZ according to the
process definition. The program XYZ is also a trigger monitor, a custom
trigger monitor.
Program XYZ has been passed the MQTMC2, so it reads it to get the
application queue name. It opens the application queue, reads and
processes the message and closes the application queue. It then goes
back into a loop where it reads the init queue. Because program XYZ has
the init queue open, MQ will not invoke another instance of program XYZ.
Every time another message arrives on the application queue, program XYZ
will get another trigger message.
This is not a classic trigger configuration, but are there problems with
it? The trigger monitor started at MQ startup time is a long running
process that basically feeds program XYZ trigger messages. Program XYZ
is also a long running process that monitors the init queue. To shutdown
the program, you have to treat it the same way as a trigger monitor -
disable the init queue for Get, but that's not a very bad thing.
I am used to the simplicity of a trigger monitor that starts an
application program, that reads application messages until
No-More-Messages, and gets triggered again when needed. That seems more
efficient, but is it?
Peter Heggie
National Grid, Syracuse, NY
This e-mail and any files transmitted with it, are confidential to
National Grid and are intended solely for the use of the individual or
entity to whom they are addressed. If you have received this e-mail in
error, please contact the National Grid USA Enterprise Support Center on
508-389-3375 or 315-428-6360.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of any
financial instrument or as an official confirmation of any transaction.
All market prices, data and other information are not warranted as to
completeness or accuracy and are subject to change without notice. Any
comments or statements made herein do not necessarily reflect those of
J.P. Morgan Chase & Co., its subsidiaries and affiliates.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
This e-mail and any files transmitted with it, are confidential to National
Grid and are intended solely for the use of the individual or entity to
whom they are addressed. If you have received this e-mail in error, please
contact the National Grid USA Enterprise Support Center on 508-389-3375 or
315-428-6360.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
