| Author |
Message
|
| WingCommanderBadger |
 Posted: Wed Aug 15, 2007 12:58 am Post subject: Channel Performance when putting messages to DLQ |
 |
|
Apprentice
Joined: 06 Sep 2005
Posts: 32
Location: London, UK
|
A customer of ours recently overlooked clearing down one of their queues to the extent that it filled up and subsequent messages were then placed on the DLQ. I noticed that there appeared to be a significant performance hit to their Receiver channel to the extent that it went into Paused status and our sender channel went into In doubt status for extended periods of time resulting in extremely slow message delivery to the other (non-full) queues on their Queue Manager (we only have one channel between us and them at the moment).
I have subsequently recreated this problem internally on our test environment and am looking into ways in which it can be avoided in the future (apart from the obvious 'Don't let the queues fill up' as this is something we don't have direct control over on customer sites).
I've had a look through the Redbooks and can't find any warning with regard to this kind of performance hit and was wondering if anyone could offer any advice? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Aug 15, 2007 1:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I would suspect (but only suspect) that the extra processing is the MCA trying to do the put, finding it can't, building and prepending the DLH then doing a 2nd put. If this is the case, I'm not certain there's much that can be done to streamline this process.
Aside from the obvious comment which you've correctly made & not let the queue fill up. You imply that clearing the queue was "overlooked"; you might want to consider automating it or better still not use a queue for medium to long term storage in the 1st place. It's always best practice to consume messages as soon as possible after arrivial.
A more esoteric point is that a full queue may not be full, it may simply be at max depth. If this is a common problem you may want to increase the maximum depth of the offending queue. Subject to genuine space restrictions of course.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Aug 15, 2007 1:30 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The channel PAUSED state is set when the RCVR MCA finds that the msg cannot be put to the dest queue. In some cases, the MCA treats this as a transient error, and retries the put. The number of retries and the interval between them is governed by the MRRTY & MRTMR (see MQSC manual) attributes of the RCVR channel. This behaviour can be altered such that no retries are attempted by setting MRRTY to zero. Fine-tuning can be done by writing a msg retry exit.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 15, 2007 1:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Nigelg wrote: |
| The number of retries and the interval between them is governed by the MRRTY & MRTMR (see MQSC manual) attributes of the RCVR channel. This behaviour can be altered such that no retries are attempted by setting MRRTY to zero. Fine-tuning can be done by writing a msg retry exit. |
The things you learn! 
Enriched by this knowledge, I'll simply add the usual note of caution about exits.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WingCommanderBadger |
| Posted: Wed Aug 15, 2007 2:00 am Post subject: Channel Performance when putting messages to DLQ |
|
|
Apprentice
Joined: 06 Sep 2005
Posts: 32
Location: London, UK
|
Excellent advice NigelG!!
Thanks to you all for your help - very much appreciated. |
|
| Back to top |
|
|
|
|
