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
