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 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. > Partridge" To: > [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: MQSeries Subject: Re: Design Review > - > custom trigger monitor vs triggered program > List > <[EMAIL PROTECTED] > n.AC.AT> > > > 07/30/2003 08:43 > AM > Please respond to > MQSeries List > > > > > > > Peter, > If program XYZ is going to be continuously running, why wouldn't it > be designed to simply do a Get with wait or just periodically check the > queue? I mean triggering is designed to start an application or process, if > it is already running then triggering is redundant. Instead of trying to > tell the consultant why he/she shouldn't do it that way, ask him/her why > they feel the need to essentially waste the resources by triggering an > application that is already running. > > Don Thomas > EDS - PASC > * Phone: +01-412-893-1659 > Fax: 412-893-1844 > * mailto:[EMAIL PROTECTED] > > > > -----Original Message----- > From: Heggie, Peter [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 29, 2003 11:17 AM > To: [EMAIL PROTECTED] > Subject: Design Review - custom trigger monitor vs triggered program > > > Hello all - would appreciate your responses on this one. > > We have someone who wants to use a custom trigger monitor to both read > the init queue message and process the application queue message. It > would be a long running process, on AIX, that waits forever (loops) on > the init queue. When a message arrives there (trigger message), it > extracts the queue name from the MQTMC2 and then opens the application > queue and processes the message. Then it goes back into the loop. > > Setup - A trigger monitor is started at MQ startup time, pointing to a > specific init queue. The first message coming into the application queue > triggers normally - MQ writes a trigger message to the init queue and > the native MQ trigger monitor starts program XYZ according to the > process definition. The program XYZ is also a trigger monitor, a custom > trigger monitor. > > Program XYZ has been passed the MQTMC2, so it reads it to get the > application queue name. It opens the application queue, reads and > processes the message and closes the application queue. It then goes > back into a loop where it reads the init queue. Because program XYZ has > the init queue open, MQ will not invoke another instance of program XYZ. > > Every time another message arrives on the application queue, program XYZ > will get another trigger message. > > > This is not a classic trigger configuration, but are there problems with > it? The trigger monitor started at MQ startup time is a long running > process that basically feeds program XYZ trigger messages. Program XYZ > is also a long running process that monitors the init queue. To shutdown > the program, you have to treat it the same way as a trigger monitor - > disable the init queue for Get, but that's not a very bad thing. > > I am used to the simplicity of a trigger monitor that starts an > application program, that reads application messages until > No-More-Messages, and gets triggered again when needed. That seems more > efficient, but is it? > > Peter Heggie > National Grid, Syracuse, NY > > > This e-mail and any files transmitted with it, are confidential to National > Grid and are intended solely for the use of the individual or entity to > whom > they are addressed. If you have received this e-mail in error, please > contact the National Grid USA Enterprise Support Center on 508-389-3375 or > 315-428-6360. > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list subscription are provided in> > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > > > > -- > > This 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 > > 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 > > 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
