Don,
Well it's one way for an application to process any number of unknown named
queues...
"Thomas, Don"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
OM> cc:
Sent by: MQSeries Subject: Re: Design Review - custom
trigger monitor vs triggered program
List
<[EMAIL PROTECTED]
n.AC.AT>
07/30/2003 08:43
AM
Please respond to
MQSeries List
Peter,
If program XYZ is going to be continuously running, why wouldn't it
be designed to simply do a Get with wait or just periodically check the
queue? I mean triggering is designed to start an application or process, if
it is already running then triggering is redundant. Instead of trying to
tell the consultant why he/she shouldn't do it that way, ask him/her why
they feel the need to essentially waste the resources by triggering an
application that is already running.
Don Thomas
EDS - PASC
* Phone: +01-412-893-1659
Fax: 412-893-1844
* mailto:[EMAIL PROTECTED]
-----Original Message-----
From: Heggie, Peter [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 11:17 AM
To: [EMAIL PROTECTED]
Subject: Design Review - custom trigger monitor vs triggered program
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
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
