| Author |
Message
|
| T4ss1nf |
 Posted: Tue May 12, 2009 6:34 am Post subject: Removing uncommitted messages from a Queue. |
 |
|
Newbie
Joined: 30 Sep 2008
Posts: 6
|
We have a queue with the Following Status:
AMQ8450: Display queue status details.
QUEUE(Q.xxxxxxxxxxxxxxxxx) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(22)
LGETDATE(2009-05-12) LGETTIME(16.12.15)
LPUTDATE(2009-05-12) LPUTTIME(16.12.15)
MONQ(LOW) MSGAGE(5567240)
OPPROCS(0) QTIME(23788, 65424)
UNCOM(YES)
My assumption is that we have an uncommitted message for 64 days.
I checked for the oldest connection on our QManager but none of them is that old.
I tried to get the content of the q file and found that indeed we have a message having some date and time tags that perfectly fit to the message age.
I don't want to restart the QManager as it is used by business critical applications.
Does anyone have an idea on how I can remove this outdated message from the Queue?
Regards,
F |
|
| Back to top |
|
 |
| zpat |
| Posted: Tue May 12, 2009 6:41 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
One of the applications has performed a MQGET and not commited it and is keeping the connection open. This is a program logic error.
If you stop that application then it will force the message to be either rolled back or removed from the queue.
It will most likely happen again unless you fix the application logic. |
|
| Back to top |
|
|
| T4ss1nf |
| Posted: Tue May 12, 2009 7:05 am Post subject: |
|
|
Newbie
Joined: 30 Sep 2008
Posts: 6
|
Only one application puts messages on this Queue and only one is reading message from it.
Unfortunately for us, this application has been stopped a few times these 64 last days and this message is still present where it should have gone.
Another question: Could it be that the sending application has performed a MQPUT and has not commited it? |
|
| Back to top |
|
|
| zpat |
| Posted: Tue May 12, 2009 7:23 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Your status display shows that 22 threads have the queue open for input and 0 for output.
Therefore it is a uncommitted MQGET.
If the application is stopped, ie disconnected, MQ will either commit or remove the message.
Therefore a uncommitted message means that unit of work is still active which usually means the application has not disconnected or stopped.
Look at the queue handle usage to work out which one it is. |
|
| Back to top |
|
|
| aditya.aggarwal |
| Posted: Tue May 12, 2009 7:42 am Post subject: |
|
|
Master
Joined: 13 Jan 2009
Posts: 252
|
Agree with Zpat..it is the application code issue.
Application should issue Commit after consuming the message from the queue.
Best Regards,
Aditya A |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 12, 2009 8:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You may also look at the manuals for the dspmqtrn command, do a search on ghost messages and remind us which XA transaction manager(s) you are using 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sumit |
| Posted: Wed May 13, 2009 1:34 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
use this command:
dis qs(qname) type(handle)
and find out the list of those 22 app. which are holding the queue. All should point to 1 application. And if that's the case, then modify your application so that it will close the queue connection handle properly before quiting.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 13, 2009 7:03 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
QUEUE(Q.xxxxxxxxxxxxxxxxx) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(22)
LGETDATE(2009-05-12) LGETTIME(16.12.15)
LPUTDATE(2009-05-12) LPUTTIME(16.12.15)
MONQ(LOW) MSGAGE(5567240)
OPPROCS(0) QTIME(23788, 65424)
UNCOM(YES) |
I am troubled by the apparent inconsistency of curdepth(0) and uncom(yes).
Any messages in the queue inside or outside a UofW would have depth greater than zero.
I'm wondering if the queue object is damaged.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 13, 2009 8:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The queue is probbaly fine.
Do a put under syncpoint and the uncommitted message will contribute to Q depth. MQBACK and the depth will go back down.
Do a get under syncpoint and the uncommitted message will drop from the queue depth. MQBACK and the depth will go back up.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 13, 2009 8:53 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
From MQSC manual:
CURDEPTH
The current depth of the queue, that is, the number of messages on the
queue. This includes both committed messages and uncommitted
messages.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 13, 2009 9:06 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I just tested this. MQ 6.0.2.4. MQ Client app running on my laptop connecting to the QM on my laptop. Put a committed message to the queue, depth = 1.
Fire up my VB.net app and step thru the code. Right after the MQGET with syncpoint, the IPROCS equals 1, the depth equals zero. Kill the debug session which rollsback the message and the depth goes back to 1.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 13, 2009 9:13 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Whoa! PMR time.
Anyone from Hursley care to offer some insight?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bbburson |
| Posted: Wed May 13, 2009 1:49 pm Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| bruce2359 wrote: |
From MQSC manual:
CURDEPTH
The current depth of the queue, that is, the number of messages on the
queue. This includes both committed messages and uncommitted
messages. |
We had a situation awhile back where a queue kept having more than MAXDEPTH number of messages on it. It took some time to figure out what was happening: an app was doing lots of gets without committing and eventually failing. The rolled-back messages plus the other messages on the queue pushed it right past the limit without batting an eye. |
|
| Back to top |
|
|
| sumit |
| Posted: Thu May 14, 2009 8:56 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| bruce2359 wrote: |
CURDEPTH
The current depth of the queue, that is, the number of messages on the
queue. This includes both committed messages and uncommitted
messages. |
What we have seen often is, xmitq displays 0 curdepth with UNCOM(YES) and the svr channel in retry mode. Did a resolve channel backout, and messages are back in the queue.
Surprised to see if message stays in q and only a copy is send to destination qmgr and this original msg is not discarded until the copy of msg is reached properly to end site q then how come msg count of xmitq is not correct. Is this anyway related to the maximum uncommitted messages capacity of qmgr? 
_________________
Regards
Sumit |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 14, 2009 9:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Found this searching Mr. Google for hursley+curdepth: http://hursleyonwmq.wordpress.com/2007/02/06/what-messages-are-included-in-curdepth/
What messages are included in CURDEPTH?
February 6, 2007 in webspheremq | by Russell Finn
If you have trouble remembering what messages are included and excluded from the CurrentQDepth of a queue, the easy way to remember is that we expect all units of work to commit. So it goes down as soon as you do an MQGET, and it goes up as soon as you do an MQPUT.
The CurrentQDepth documentation in the Application Programming Reference does describe this but to my mind it reads like a set of rules to be learned. I remember things much better when given a model that I can understand.
CurrentQDepth is the number of messages currently on the queue. It is incremented during an MQPUT call, and during backout of an MQGET call. It is decremented during a nonbrowse MQGET call, and during backout of an MQPUT call. The effect of this is that the count includes messages that have been put on the queue within a unit of work, but that have not yet been committed, even though they are not eligible to be retrieved by the MQGET call. Similarly, it excludes messages that have been retrieved within a unit of work using the MQGET call, but that have yet to be committed.
The count also includes messages that have passed their expiry time but have not yet been discarded, although these messages are not eligible to be retrieved. See MQMD Expiry for more information.
Unit-of-work processing and the segmentation of messages can both cause CurrentQDepth to exceed MaxQDepth. However, this does not affect the retrievability of the messages; all messages on the queue can be retrieved using the MQGET call in the normal way.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
