| Author |
Message
|
| MQ123 |
 Posted: Mon Apr 28, 2008 5:12 am Post subject: Channel Performance when putting messages to DLQ - Part 2 |
 |
|
Novice
Joined: 05 Jun 2007
Posts: 11
|
Under
http://mqseries.net/phpBB2/viewtopic.php?p=187908&highlight=&sid=bdf5f3c2b4db6900b513641cce25b340
I found the topic about performance issues because the channel PAUSED when the RCVR MCA finds that the msg cannot be put to the destination queue.
The solution suggested was to set the MRRTY & MRTMR to zero so that the message will delivered immediately to the DLQ.
But this solution will be only a reaction to a symptom which is from my point of view a questionable design issue: Why is the channel going down when one queue (of maybe 100) has a problem (overflow)? I expect, that the deliver retry will not influence the status of the channel at all.
As a consequence one overflow of one queue will bring down your whole traffic between your two Queuemanagers. I think, that is not acceptable. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Apr 28, 2008 5:27 am Post subject: Re: Channel Performance when putting messages to DLQ - Part |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQ123 wrote: |
| But this solution will be only a reaction to a symptom which is from my point of view a questionable design issue: Why is the channel going down when one queue (of maybe 100) has a problem (overflow)? I expect, that the deliver retry will not influence the status of the channel at all. |
WMQ is designed as an assured delivery mechanism. If a message is undeliverable then the priority is given to the integirty of the message flow. So an undeliverable message will cause the channel to pause while it resolves the problem (which could be transitory).
| MQ123 wrote: |
As a consequence one overflow of one queue will bring down your whole traffic between your two Queuemanagers. I think, that is not acceptable. |
Don't forget that an overflow of a queue is an emergency situation; it shouldn't happen ever in a normal running system. In emergencies, throughput drops while the emergency is handled. The thread you quote is a way of mitigating this problem, but I stand by what I said in that thread - proper housekeeping and monitoring is the better way of dealing with this sort of problem. While you need an effective sprinkler system in a building, it's essential you have both a fire alarm & rules about throwing lighted cigarette butts into waste paper bins!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Apr 28, 2008 5:40 am Post subject: Re: Channel Performance when putting messages to DLQ - Part |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| MQ123 wrote: |
| As a consequence one overflow of one queue will bring down your whole traffic between your two Queuemanagers. I think, that is not acceptable. |
If the system design says that this situation should be avoided, then have more than one channel, each offering differing levels of service - eg. one carrying messages to queues that are well-drained, and one carrying messages to queues that are sometimes/always not well-drained. Or, have many separate channels, one for each distinct flow. The configuration possibilities are there in order to do what is being asked. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Apr 28, 2008 6:41 am Post subject: Re: Channel Performance when putting messages to DLQ - Part |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| MQ123 wrote: |
Why is the channel going down when one queue (of maybe 100) has a problem (overflow)? I expect, that the deliver retry will not influence the status of the channel at all.
As a consequence one overflow of one queue will bring down your whole traffic between your two Queuemanagers. I think, that is not acceptable. |
The channel is not going down, its doing what you told it to do:wait and retry the message in x milliseconds. Set both values to zero and you won't have this problem when one queue fills up. Then when your DLQ fills up the channel will hard stop and no messages will come across at all until you make room in the DLQ.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MQ123 |
| Posted: Tue Apr 29, 2008 4:35 am Post subject: |
|
|
Novice
Joined: 05 Jun 2007
Posts: 11
|
Thanks for the replys !
I forgot to mention that the channel between the two Queuemangers was a Clusterchannel.
Today I tested to set the retry setting to zero on the receiver side and as expected the DLQ was filled immediately and the channel keep on running.
So this would be an alternative.
In our case we have a request reply pattern to pick up information from backend systems where the focus lies on perfomance and not on asured delivery ... |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 29, 2008 4:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQ123 wrote: |
| In our case we have a request reply pattern to pick up information from backend systems where the focus lies on perfomance and not on asured delivery ... |
Then you're probably using non-persistent messages anyway. You should certainly be using expiry, and hence the problem isn't a problem unless you have a very badly performing backend system and a ridiculously small maxdepth.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
