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

Reply via email to