Paul, Why such reticence? It answers the question splendidly. The description in the command manual is somewhat light, but Intercommunication is much more detailed. The message retry parameters act like a flood plain when a message consumer is over-loaded, giving it a chance to catch up without a failure by backing up messages in the channel. So the default values make sense, don't impact hard failures and therefore shouldn't be switched off.
Many Thanks Alan -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Clarke Sent: 17 November 2004 10:18 To: [EMAIL PROTECTED] Subject: Re: Receiver channel parameters mrrty and mrtmr Alan, I'm not sure it answers your question but you seem to indicate that the mesage is retried regardless of the failure. This isn't true, there are only a small number of errors which are considered transitory (and therefore retryable). From memory these are MQRC_PUT_INHIBITED MQRC_RESOURCE_PROBLEM MQRC_STORAGE_NOT_AVAILABLE MQRC_Q_SPACE_NOT_AVAILABLE MQRC_Q_FULL So, in the case you cite where the queue does not exist we would not try and retry and the message would be immediately dumped to the DLQ. Cheers, P. Paul G Clarke WebSphere Messaging Clients IBM Hursley MQSeries List <[EMAIL PROTECTED]> wrote on 17/11/2004 09:33:37: > 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 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
