| Author |
Message
|
| Mq_learner |
 Posted: Mon Aug 22, 2005 6:55 pm Post subject: How to deal if queue reaches max depth. |
 |
|
Newbie
Joined: 22 Aug 2005
Posts: 3
Location: Chicago
|
Hi,
Can any one tell me a solution what if a queue reaches its max depth. I can see that messages are going to dead letter queue. Is there a mechanism to retrive messages from dead letter queue or is there an alternate approach to prevent messages from going to dead letter queue and manage max depth situation with some java program. Of course, I have a monitoring system in place that will alert when max depth is reaching. Still I want some way to deal the max depth situation.
Thanks, |
|
| Back to top |
|
 |
| hopsala |
| Posted: Mon Aug 22, 2005 7:17 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
By design, messages which have no where to go (if, for example, target queue is filled) are supposed to go to the dead letter queue. To handle those messages, you run a dead letter queue handler (command runmqdlq) which according to a rule table (that you can customize), retrieves messages from the deadq and retries sending them to targetq or does whatever else you want it to do. A full description can be found in System Administration Guide or around this site - there are thousands of posts on this topic...
If for some reason you do not want msgs in your deadq either delete it or put-inhibit it - it should do the trick. Keep in mind, though, that if a queue fills and there is no dead letter queue, all channels trying to write to the full queue will go into RETRY, meaning messages targeted for other queues will not be sent until that one problematic queue is emptied.
Anyway, you can find more info by either reading the manuals or clicking the "search" button here and reading a little; make it a habit clicking this button before posting. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Aug 22, 2005 7:24 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| hopsala wrote: |
| Keep in mind, though, that if a queue fills and there is no dead letter queue, all channels trying to write to the full queue will go into RETRY, meaning messages targeted for other queues will not be sent until that one problematic queue is emptied. |
Actually the channel will go to STOPPED, not RETRYING. At that point you will need to make room in the destination queue, and/or in the DLQ, and then manually restart the channel.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hopsala |
| Posted: Mon Aug 22, 2005 11:42 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Um, that's not true.
Just made the experimet to make sure - channel is in RETRY...
(The whole point is that it goes to retry, and when the problem is resolved is goes up automatically; what's the sense in stopping?) |
|
| Back to top |
|
|
| KeeferG |
| Posted: Tue Aug 23, 2005 1:45 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
Hi guys,
Don't foprget the different behaviour in clustering. It's caused all sort of headaches for us.
Queue fills. receiving end goes through its MRRTY loops, default 10 attempts, 1 second apart, before placed on DLQ, repeated for batch of 50.
Sending end stays running for ever and messages build up on transmit queue.
Net result is sending end thinks everything is fine and receiving end always in a paused state. Final killer is new amqrmppa process spawning on the receiving end finally killing the box.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Aug 23, 2005 7:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
hopsala,
You are correct! I just tried it myself, and the channel does go RETRYING, whether the DLQ is full or not defined, and then goes RUNNING as soon as the problem is fixed. That's the way it should work.
The reason I said it would go STOPPED was the following quote from page 13 of the Intercommunications manual, and what I was taught early on in my MQ classes:
| Quote: |
We recommend that you define a dead-letter queue for each queue manager. If you
do not, and the MCA is unable to put a message, it is left on the transmission
queue and the channel is stopped.
|
The manual is wrong?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| EddieA |
| Posted: Tue Aug 23, 2005 7:44 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| The manual is wrong |
Maybe. Or maybe not explicit enough.
I haven't time to test, but perhaps the channel only goes into RETRY for a Queue Full, which "should" be transitory. Maybe a Queue Not Found, or other errors, might cause the Channel to shut down.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Mq_learner |
| Posted: Tue Aug 23, 2005 7:50 am Post subject: |
|
|
Newbie
Joined: 22 Aug 2005
Posts: 3
Location: Chicago
|
| As a new member, I am really surprised to see immediate responce. Thanks, and please continue. I am trying to implement here. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Aug 23, 2005 7:54 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| EddieA wrote: |
| Quote: |
| The manual is wrong |
Maybe. Or maybe not explicit enough.
I haven't time to test, but perhaps the channel only goes into RETRY for a Queue Full, which "should" be transitory. Maybe a Queue Not Found, or other errors, might cause the Channel to shut down.
Cheers, |
Nope, thought of that. Sent to a bogus Q name, and same results.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 23, 2005 8:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It is perfectly valid to file a PMR on documentation, and to request clarification of documentation...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hopsala |
| Posted: Tue Aug 23, 2005 9:32 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Happily I haven't trusted the manuals (by instinct) for years now  I always try things out before relying on them; But I am really surprised to see such a blunt mistake in the manuals, and on all books in the Intercommunication manual - i.e the bible - Can a simple MQ admin believe in nothing nowadays?
Btw, through the years I had every possible problem - queue does not exist, 2035, 2033, message too big for queue, no deadq, deadq full, put-inhibit and more - the channel always goes to RETRY.
In fact, the only case I found channels going to STOPPED is after LONGRTY is done or some serious memory-allocation error and such.
| KeeferG wrote: |
Queue fills. receiving end goes through its MRRTY loops, default 10 attempts, 1 second apart, before placed on DLQ, repeated for batch of 50.
Sending end stays running for ever and messages build up on transmit queue. |
Yup, that's why I always work with MRRTY of 1 or 2. I claim that if there's a problem putting to queue, it will probably still be there in the next few minutes...
Last edited by hopsala on Tue Aug 23, 2005 9:37 am; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 23, 2005 9:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| hopsala wrote: |
| In fact, the only case I found channels going to STOPPED is after LONGRTY is done or some serious memory-allocation error and such. |
This does actually mean that the manual is correct.
It does not say when the channel will be stopped. Nor does it say what criteria is used to determine that "the MCA is unable to put a message".
Like a lot of things in the manuals, though, this is subtle.
EDIT:
Heck, I'd even argue that this is the *right* behavior. Most conditions that will cause the MCA to get a bad RC from a PUT are transitory conditions, and will likely be resolved before the LONGRTY is over. Once the problem is resolved on the receiving side, I want the channel to resume normal operations without intervention, and messages to flow. I don't want to have to start the channel as well, or resolve messages on the xmit queue in some manner.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Tue Aug 23, 2005 9:41 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| It does not say when the channel will be stopped |
Umm... using the default values, that would be a little more than 38,051 years.... 
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 23, 2005 9:43 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| wschutz wrote: |
| Quote: |
| It does not say when the channel will be stopped |
Umm... using the default values, that would be a little more than 38,051 years.... |
I thought it was IBM's general position that the default values were not really designed for production use? 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Tue Aug 23, 2005 9:49 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Actually Peter, if you're looking at the info center version of the Intercomm guide, you can just click the "Feedback" link at the bottom of the offending page and make a comment about it there.....
Jeff... I wonder how many people have actually changed long retry?
_________________
-wayne |
|
| Back to top |
|
|
|
|
