| Author |
Message
|
| pbravic |
 Posted: Sun Apr 11, 2004 8:08 pm Post subject: MQ Queue Capacity - Issue |
 |
|
Apprentice
Joined: 24 Nov 2003
Posts: 42
|
Hi
we have MQ 5.2. one of the queue is reaching its maximum size of 2 gb, so the messages for that queue are backed out. after deleting some messages (3000 msgs- immediate soln) , the queue was able to take the input. but after 2 days it again reached its limit
we tried to empty all the messages and still find the queue file size shows 1.99 gb, there is no actual reduction in size.
As there is no support for MQ 5.2 we were not able to contact IBM, pls let us know how to find the root cause and solve the same.
Thanks and Regards
Ravi |
|
| Back to top |
|
 |
| kman |
| Posted: Mon Apr 12, 2004 12:06 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
You should check your application. Why it is not 'GETTING' the messages off the queue. Do not use the queue as a database.
Make sure your application GETs the messages from the queue. That way, the queue is being serviced and the messages are removed from the queue and you won't get into this trouble.
As far as I can tell, right now your problem is not about its filling up the queue, but the slowness of the application serving the queue. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Mon Apr 12, 2004 6:03 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
You shouldn't be looking at the file size of the queue to determine how full your queue is. MQ will grow and shrink this file as it sees fit. If you get a bunch of messages off of the queue, the file may not shrink immediately. Look at the curdepth of the queue to get a better feel for how many messages are on the queue.
I'll second kman's advice on not using a queue for a database. You should be putting messages onto the queue with the intent of getting them off not keeping them there.
Also, I'd strongly suggest that you move forward to WMQ 5.3. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Tue Apr 13, 2004 12:56 pm Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
| I believe that the queue file will not shrink on disk until all messages are gone (you may even have to do a clear qlocal, not sure about that) and there are no IPPROCs or OPPROCs on the queue. Restarting your queue manager will also reclaim the "white space" in your queue file, I think. |
|
| Back to top |
|
|
| pbravic |
| Posted: Wed Apr 14, 2004 7:24 am Post subject: |
|
|
Apprentice
Joined: 24 Nov 2003
Posts: 42
|
Hi all
Thanks for the inputs we will be able to restart the QM in the next maintanence window.
The design was already done and we are maintaining the same
The Queues are not actually used as database. the messages are having expiry limit of 15 days , we are planning to have a seperate utility to issue a get so that expiry messages gets refreshed (It is not part of the issue).
We are also in the process of migration from 5.2 to 5.3
Thanks again for your inputs
Thanks and Regards
P.B.Ravichandran |
|
| Back to top |
|
|
| tkane |
| Posted: Thu Apr 15, 2004 7:22 am Post subject: |
|
|
Voyager
Joined: 23 Dec 2002
Posts: 82
Location: Kansas City
|
I don't want to sound like I'm trying to hammer you Ravi, but most expirys that I've delt with in 7 years of MQ have been on the order of seconds or minutes. Not DAYS.
If the messages need to be around that long then the application should put them in a DB. One designed to have GBs worth of data. IMO MQ doesn't do GB worth of data as well as it does smaller amounts. And how much logging do you need for that big a queue as well.
Good luck 
Tom |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 15, 2004 12:36 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I push for Expiry in days. If a message arrives after the application was waiting for it gave up, it is an orphaned message that will not get consumed. If the expiry is a few seconds or minutes after that, the message goes away on its own (if the queue has any GET activity on it), and you have no evidence of there ever being a problem. If the app is an Inquiry style app where users just reissue the request, no one complains when they timeout waiting for the reply and you never know there is a problem.
If you put an Expiry with 5 days, after a week you will accumalate those orphans. By looking at their put times, you can establish a pattern. Maybe every day between noon and 2, there are many orphans. Now you have evidence at hand that there is a problem and when it happens.
If your queue would fill up with so many orphans in a couple days that the queue over flows, you got major issues anyway with some app not performing properly.
If you can be sure that the getting app will report every 2033 to you, then maybe you don't need the orphans to hang around, but even then, I think the evidence is worthwile to have.
If you set Expiry to several days and the queues are empty, you know everything is coming back in time. If all the orphans blink away seconds after they are orphaned....
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 15, 2004 4:29 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| If the expiry is a few seconds or minutes after that, the message goes away on its own (if the queue has any GET activity on it), and you have no evidence of there ever being a problem. |
Well, surely that's only true if the sending application hasn't made any record that it sent a message, right?
And all MQSeries apps are written to provide full and accurate information about what they do for later analysis. 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu Apr 15, 2004 5:32 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
I think what jeff, peter and others have expressed is more of a design choice IMO and it may differ depending upon the requirement and what one perceives is best for their environment. And that means, all of the suggestions/opinions are correct in thier own contexts.
And the same design issue is the most likely cause of the problem with ravi too, IMO. Some questions.
-Why is this one queue so overburdened.
-Why dont you share the work-load onto multiple queues.
-Possibly define and use queues depending upon the business logic rather than using business logic in your apps and using one queue. Overhead to queues, Mq, transaction monitor(if one is used)... and the list can just go on.
-If your design needs messages to be put with 15 days of expiry, then you should also cater to situations where you deal with the messages that have already expired on the queue.
-
-
-
-And the list can just go on.
Bottom line is, everything has a limit and if that limit/threshold is hit, you have to find out why it happened and resolve it rather than concentrating to resolve the limit/threshold itself.
Good luck!!!
Cheers
Kumar |
|
| Back to top |
|
|
| pbravic |
| Posted: Wed Apr 21, 2004 1:22 pm Post subject: |
|
|
Apprentice
Joined: 24 Nov 2003
Posts: 42
|
Hi All
Thanks for the inputs, yes I do agree we need to look in to the design. For that ther needs an lot of aproval process and even though it will not be an immediate solution we will go for it.
We are planning to reduce the expiry limit from 15 to 7 days
we will be migrating to 5.3 shortly, I think there is a feature in 5.3 for the queue to hold more than 2gb of data. for the interim solution pls let me know how to increase the queue file size capacity in mq 5.3 on windows
Thanks and Regards
Ravi |
|
| Back to top |
|
|
| pbravic |
| Posted: Thu Apr 22, 2004 7:04 am Post subject: |
|
|
Apprentice
Joined: 24 Nov 2003
Posts: 42
|
hi
Just got clarified from IBM, the queue file size is not limited onf 5.3 on windows 2000, it will be fine as long as the os supports the same.
but its an only an interim solution, we are revisiting the design.
Thanks for the inputs
Thanks and Regards
Ravi |
|
| Back to top |
|
|
|
|
