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
|
|
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
