The
classic example of this is for 3rd party connections (which for security reasons
are usually dedicated to a single business partner or app). In
situations where there is a gateway QMgr in the DMZ that serves multiple 3rd
parties the channel retry can isolate the 3rd parties from one
another. With a low or non-existent retry, one business
partner could execute an attack on the QMgr and fill the DeadQ with large
messages in an attempt to knock out the QMgr. Raising the retry interval
and count in this situation provides flood protection.
Thanks
to Peter Potkay for teaching me that one. We had a vendor program get into
a loop recently. Had we been using the defaults or no retry at all, they
might actually have run us out of disk space.
--
T.Rob
-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Jim Ford
Sent: Wednesday, November 17, 2004 11:10 AM
To: [EMAIL PROTECTED]
Subject: Re: Receiver channel parameters mrrty and mrtmr
The problem we saw with the defaults is that a single application queue could cause a channel to go into retry. But the channel will service loads of queues. So if a problem application fills up a queue, the channel grinds to a halt and more responsible application suffer, too. Because of that, we chose to set MRRTY to zero on nearly all of our receiver channels. The only exception is for channels dedicated to a single application. If those channels go into retry because of a put inhibited queue, or a full queue of pageset, that's fine with us.
"Lovett, Alan J" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>11/17/2004 03:33 AM
MQSeries List <[EMAIL PROTECTED]>
[EMAIL PROTECTED] Receiver channel parameters mrrty and mrtmr
Hi,
We have been asked to justify our decision to let receiving channel message
retry count and interval parameters (mrrty and mrtmr) take their default
values. These allow (non z/OS) MQ to retry message put failures up to 10
times, one second apart, before writing the message to the dead letter
queue. For the obvious reasons (no such queue, expired temporary dynamic
queue), there seems little point to the retries, and reasonable concern over
possible backlogs following a transient hold-up, e.g. network hitch.
To the question - Is anyone aware of sound reasons for keeping the default
values as they are? Is there a reasonably common condition that causes a
temporary inability to deliver valid messages, that is overcome via the
retries? I find myself wondering about MQ internal checkpointing, or lock
activity type stuff.
My thanks to all who take the time to read this, especially if they share
their experience with us all.
Alan
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
