Re: Design Review - custom trigger monitor vs triggered program
Pavel Maybe I'm just being a little think here, but I'm not understanding how removing our dead letter queues would help these situations that you mention. First of I'm leaving message order out of the picture because that agreed is a holy war I don't want to get into. Secondly I agree that you certainly have issues to deal with managing the dead queue and the messages that land there. However it seems to me that you have far more issues to deal with if you do not allow the queue manager to use a dead queue. If you are referring to application writing to the dead queue, I agree I would not endorse using a dead queue as an applications poison/retry queue. That would be best for that business logic to deal with on their own queues. But the queue manage is a nother story. I would never run a queue manager without a dead queue. I have no desire to be called at all hours because one application messed up the whole channel. Without a dead queue for the queue manager to route undeliverable messages, what processes are you going to need in place to keep your channels and XMIT queues healthy and functioning? I certainly don't want business logic messing with my XMIT queues. I also would be no more pleased to go searching all the XMIT queues (talk about security policies) for a particular messaging problem, than I would be to have to find it in the dead queues. I know I'd rather have the errant message dumped into the dead queue and the rest of the good messages be transmitted. (I know of no business unit that will accept the other guys program has a problem as an excuse for why their production applications can't run.) At least there are plenty of usable dead letter handlers out there that can be configured to resolve or route messages off the dead queue. If messages are stuck in the XMIT queue on the other hand, then you've got real problems and I know of no automated process that is going to save you. As for other asynchronous message systems, I'm curious how they assure message delivery and keep the channels between servers open and flowing freely without something similar on one end or the other. Rick |-+--- | | Pavel Tolkachev | | | [EMAIL PROTECTED]| | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Wednesday July 30, 2003 10:46 AM| | | Please respond to MQSeries List | | | | |-+--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Design Review - custom trigger monitor vs triggered program | | Hello Dave, Well, it is almost religious thing, so I was hesitant to touch the theme. But if you ask :-): 1. It breaks the default message order guarantees MQ series normally provides. 2. It requires handling, and because, after the close look, each application has slightly different requirements to handle it, it turns our that 2 must be developed instead of one for each task: one to process the normal flow and another to process messages from dead letter. And handlers must be worked out in terms of security and other application management issues. Considering the policy for actioning on nondeliverable messages a part of business logic seems more appropriate to me. 3. When using distributed messaging, you may have a nice encounter every time a user compains his/her application did not receive some particular message you may have to search for it in dead letter queues (read trush cans :-) ) across the globe -- breaking all security policies on your way etc.. 4. DLQ does not have analogs in other messaging systems I have to use, so using it reduces interoperability and portability of the software and (business) processes -- if you use it. Hopefully, this won't start another holy war.. This is just my opinion, very humble, and I am in no way MQ expert. Just take it as another weird thing I heard if you feel strongly disagree. Pavel David C. PartridgeTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc
Re: Design Review - custom trigger monitor vs triggered program
I agree. Without a DLQ, you risk channels shutting down, trigger monitors stopping, and other undesireable side-effects in the event of mis-behaving applications, networks, and opertors. Now I would not recommend designing an application around the DLQ, but it's good to have it there as a last-gasp safeguard to keep messages flowing when something goes south. The goal would be to make appearances in the DLQ a rarity. When a message shows up there, the alerts go out as it signals a problem that needs to be fixed. Better to have the DLQ as a cushion so messages can keep flowing while the problem is being chased. The notion of poking around in DLQ's for lost messages is backwards. A message in the DLQ should be regarded as a found problem not a lost message. -Original Message- From: Richard Brunette [SMTP:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 7:31 AM To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Pavel Maybe I'm just being a little think here, but I'm not understanding how removing our dead letter queues would help these situations that you mention. First of I'm leaving message order out of the picture because that agreed is a holy war I don't want to get into. Secondly I agree that you certainly have issues to deal with managing the dead queue and the messages that land there. However it seems to me that you have far more issues to deal with if you do not allow the queue manager to use a dead queue. If you are referring to application writing to the dead queue, I agree I would not endorse using a dead queue as an applications poison/retry queue. That would be best for that business logic to deal with on their own queues. But the queue manage is a nother story. I would never run a queue manager without a dead queue. I have no desire to be called at all hours because one application messed up the whole channel. Without a dead queue for the queue manager to route undeliverable messages, what processes are you going to need in place to keep your channels and XMIT queues healthy and functioning? I certainly don't want business logic messing with my XMIT queues. I also would be no more pleased to go searching all the XMIT queues (talk about security policies) for a particular messaging problem, than I would be to have to find it in the dead queues. I know I'd rather have the errant message dumped into the dead queue and the rest of the good messages be transmitted. (I know of no business unit that will accept the other guys program has a problem as an excuse for why their production applications can't run.) At least there are plenty of usable dead letter handlers out there that can be configured to resolve or route messages off the dead queue. If messages are stuck in the XMIT queue on the other hand, then you've got real problems and I know of no automated process that is going to save you. As for other asynchronous message systems, I'm curious how they assure message delivery and keep the channels between servers open and flowing freely without something similar on one end or the other. Rick |-+--- | | Pavel Tolkachev | | | [EMAIL PROTECTED]| | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Wednesday July 30, 2003 10:46 AM| | | Please respond to MQSeries List | | | | |-+--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Design Review - custom trigger monitor vs triggered program | | Hello Dave, Well, it is almost religious thing, so I was hesitant to touch the theme. But if you ask :-): 1. It breaks the default message order guarantees MQ series normally provides. 2. It requires handling, and because, after the close look, each application has slightly different requirements to handle it, it turns our that 2 must be developed instead of one for each task: one to process the normal flow and another to process messages from dead letter. And handlers must
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 efficient, but is it? Peter Heggie National Grid, Syracuse, NY This e-mail and any files transmitted
Re: Design Review - custom trigger monitor vs triggered program
Oh NO It's the Consultants are always right syndrone. (Even when they are wrong.) This is giving me a bad name!!! (More than I usually do for myself). This looks like a job for The Objective Reasoning super hero!!! Oh sorry, he has already spoken!!! (sorry I couldn't resist!!) bobbee 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 15:01:01 -0400 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
Re: Design Review - custom trigger monitor vs triggered program
Its..OBJECTIVE REASONING MAN.. ! Its not too late to restore the good name of [EMAIL PROTECTED] Thanks everybody! I think I've got enough now! Peter Heggie (315) 428 - 3193 -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 7:34 AM To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Oh NO It's the Consultants are always right syndrone. (Even when they are wrong.) This is giving me a bad name!!! (More than I usually do for myself). This looks like a job for The Objective Reasoning super hero!!! Oh sorry, he has already spoken!!! (sorry I couldn't resist!!) bobbee 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 15:01:01 -0400 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 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
Re: Design Review - custom trigger monitor vs triggered program
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
Re: Design Review - custom trigger monitor vs triggered program
Thanks Don! I thought I was the only one and so was keeping the embarassed silence :-). In my personal list of bad things to do the unfounded use of triggering (and when is it actually well founded?) sits right next to defining default queue managers, dead letter queues and couple of other things like breaking the guarantees of natural order of messages in queues and then using groups to get things together. Just as a side note.. Pavel Thomas, Don [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: 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 e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 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
Re: Design Review - custom trigger monitor vs triggered program
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: MQSeriesSubject: 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
Re: Design Review - custom trigger monitor vs triggered program
I agree with Paval on the DLQ issue. Unless you are prepared to process the DLQ and your applications can suffer both delayed and out of sequence messages you really shouldn't use on. Also, if some errant queue manager is sending your queue manager messages to queues which do not exist, the errant queue manager can fill up you DLQ causing all kinds of problems. You should really consider all the issues when using it. David C. PartridgeTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RIMEUR.COM Subject: Re: Design Review - custom trigger monitor vs triggered program Sent by: MQSeries List [EMAIL PROTECTED] .AC.AT 07/30/2003 10:19 AM Please respond to MQSeries List Pavel, could you expand on why you think that defining a default dead letter queue is a bad thing? When I define a QM I always use -u SYSTEM.DEAD.LETTER.QUEUE. I'd agree on all the other things as being sins, though whether they are deadly or merely venal is possibly arguable (I'd go for deadly myself). Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Pavel Tolkachev Sent: 30 July 2003 14:18 To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Thanks Don! I thought I was the only one and so was keeping the embarassed silence :-). In my personal list of bad things to do the unfounded use of triggering (and when is it actually well founded?) sits right next to defining default queue managers, dead letter queues and couple of other things like breaking the guarantees of natural order of messages in queues and then using groups to get things together. Just as a side note.. Pavel Thomas, Don [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: 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
Re: Design Review - custom trigger monitor vs triggered program
Hello Dave, Well, it is almost religious thing, so I was hesitant to touch the theme. But if you ask :-): 1. It breaks the default message order guarantees MQ series normally provides. 2. It requires handling, and because, after the close look, each application has slightly different requirements to handle it, it turns our that 2 must be developed instead of one for each task: one to process the normal flow and another to process messages from dead letter. And handlers must be worked out in terms of security and other application management issues. Considering the policy for actioning on nondeliverable messages a part of business logic seems more appropriate to me. 3. When using distributed messaging, you may have a nice encounter every time a user compains his/her application did not receive some particular message you may have to search for it in dead letter queues (read trush cans :-) ) across the globe -- breaking all security policies on your way etc.. 4. DLQ does not have analogs in other messaging systems I have to use, so using it reduces interoperability and portability of the software and (business) processes -- if you use it. Hopefully, this won't start another holy war.. This is just my opinion, very humble, and I am in no way MQ expert. Just take it as another weird thing I heard if you feel strongly disagree. Pavel David C. PartridgeTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RIMEUR.COM Subject: Re: Design Review - custom trigger monitor vs triggered program Sent by: MQSeries List [EMAIL PROTECTED] .AC.AT 07/30/2003 10:19 AM Please respond to MQSeries List Pavel, could you expand on why you think that defining a default dead letter queue is a bad thing? When I define a QM I always use -u SYSTEM.DEAD.LETTER.QUEUE. I'd agree on all the other things as being sins, though whether they are deadly or merely venal is possibly arguable (I'd go for deadly myself). Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Pavel Tolkachev Sent: 30 July 2003 14:18 To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Thanks Don! I thought I was the only one and so was keeping the embarassed silence :-). In my personal list of bad things to do the unfounded use of triggering (and when is it actually well founded?) sits right next to defining default queue managers, dead letter queues and couple of other things like breaking the guarantees of natural order of messages in queues and then using groups to get things together. Just as a side note.. Pavel Thomas, Don [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: 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
Re: Design Review - custom trigger monitor vs triggered program
what is embarassing is inheriting an environment where the use of triggers actually produced the opposite effect the interesting part was that if the count exceeded the factor used to invoke the trigger, it would never activate the trigger, so scheduling the triggered job twice a day always cleared it back to stage zero so it could self correct however the interesting one was the group that added a wait of 30 seconds to a message queue that triggered a job about every 2 minutes ( when actually removing the trigger and scheduling the job every 8 hours accomplished the same results, with a 70% reduction in batch jobs being run (this was a daily process function per division) now on the other queue which is set to first, has no wait in it, so it acts like EVERY and triggers 1000 jobs an hour (can't convince them to add the wait) I did download the MA12 support pac to get the quiesce code (since they were cancelling the trigger STC) I actually find the trigger fascinating (but it does have its share of quirks) Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] If one of the engines on a two engine plane fails The other engine will always get you to the site of the crash -- Pavel Tolkachev [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/30/2003 08:17 AM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:Re: Design Review - custom trigger monitor vs triggered program Thanks Don! I thought I was the only one and so was keeping the embarassed silence :-). In my personal list of bad things to do the unfounded use of triggering (and when is it actually well founded?) sits right next to defining default queue managers, dead letter queues and couple of other things like breaking the guarantees of natural order of messages in queues and then using groups to get things together. Just as a side note.. Pavel Thomas, Don [EMAIL PROTECTED]To:[EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: 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
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
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
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 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
Re: Design Review - custom trigger monitor vs triggered program
-Original Message- From: Heggie, Peter [SMTP:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 8: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
Re: Design Review - custom trigger monitor vs triggered program
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 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
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 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
Re: Design Review - custom trigger monitor vs triggered program
Sorry about the blank response(s); I seem to have fat fingers today. First, assuming your design would work, I cannot tell that it accomplishes anything useful. What is your customer's aim? You said Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. Not true. An open initq is a triggering requirement; it does not suppress trigger messages. You said Every time another message arrives on the application queue, program XYZ will get another trigger message. If you trigger on EVERY, the INITQ will indeed receive another trigger message. But, you have the native trigger monitor (NTV) and XYZ competing for trigger messages. At first, most of them will be captured by NTV because XYZ has other work to do. Each time NTV will spawn a new instance of XYZ, adding to the contention. Even if you could somehow quiesce NTV after XYZ takes over, the design of XYZ does not scale. While XYZ is processing the INITQ it cannot process the application queue(s) and visa versa. That may be tolerable for a single application, but consider what happens when your second triggered application comes along. You have a design where one triggered application (XYZ) is processing all triggered queues. Not only is that a processing bottleneck, but it's forced to an inefficent programming model--open q, read msg, process msg, close q--because each TM has the potential to reference a different application queue. Need I even mention the maintenance implications of having XYZ process every different kind of message that flows through every triggered queue. If you are intending that your custom trigger monitor be dedicated to a single application queue, then you have you have missed the point of triggering. The idea of monitoring an INITQ is so that you don't need a long running task for each application queue. If you restrict your INITQ to a single application, you gain nothing--might as well just monitor the application queue. You should also take care not to fall in the trap that trigtype EVERY gives a one-to-one relationship between trigger messages and application messages. The triggered EVERY app generally needs to loop on the triggered queue until empty in order to pick up orphan messages. Given that, as XYZ is emptying the triggered queue, more trigger messages will appear. Those that are picked up by NTM will invoke another XYZ. Those picked up by one of the XYZ's will have no messages to process. Now, if trigtype=FIRST, then XYZ will fire only once while app queue is open. In that case, I see no useful purpose for XYZ going after the INITQ. regards, Dennis -Original Message- From: Heggie, Peter [SMTP:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 8: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
Re: Design Review - custom trigger monitor vs triggered program
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 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
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 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
