AW: Design Review - custom trigger monitor vs triggered program
it will not work (see also dennis post). the design is definitly wrong. that should be strong enough to change it. regards stefan -Ursprungliche Nachricht- Von: Heggie, Peter [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 21:01 An: [EMAIL PROTECTED] Betreff: Re: Design Review - custom trigger monitor vs triggered program Sorry for blank reply. The rationale is that it was delivered by a consultant. And I need something strong and obvious to change it... Peter Heggie (315) 428 - 3193 -Original Message- From: Stefan Sievert [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 2:51 PM To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Peter, what is your design rationale for having multiple initiation queues? Stefan >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: MQSeriesSubject: 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
AW: Design Review - custom trigger monitor vs triggered program
Peter, after the trigger monitor has started xyz, xyz will also listen to the initq. so you have 2 programs listening to the initq, which one will get the next trigger message? (quote on) Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. (quote off) This is wrong in my opinion. an open application queue (open for input) will prevent mq to create another trigger message. but you wrote you close the application queue. so mq will create a trigger message if the trigger conditions are fullfilled. if the trigger monitor will get it, it will start another xyz program. if you trigger and stay alive, why do you trigger? 1. no triggering at all start xyz to listen on the application queue. if a message arrives, it will get processed. use fail if quiescing (and maybe get-disable) to end your application, or use a special kind of message content (a "stop message" that will make your program to end. 2. use triggering and end trigger monitor will start xyz, xyz will process all messages and wait a specific amount of time for more messages to arrive (get-wait). if nothing arrives, then xyz ends and will be triggered again if messages arrive on the queue. 3. use triggering and stay alive trigger monitor will start xyz, xyz will process all messages and wait infinite for mor messages to arrive. no need to read the initq if you have the application queue open for input (trigger first will not be fired because of this). check how frequent messages arrive in the queue and pick up the best and less-complex solution. seperate business and technics, application programs perform application work, trigger monitor does the technical stuff. I would not use the triggered application program to do the work of the trigger monitor. Regards, Stefan -Ursprungliche Nachricht- Von: Heggie, Peter [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 17:17 An: [EMAIL PROTECTED] Betreff: 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
