|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MQ Explorer and MQSC both showing wrong current queue depth |
« View previous topic :: View next topic » |
Author |
Message
|
vicks_mq |
Posted: Fri Dec 28, 2018 6:11 am Post subject: MQ Explorer and MQSC both showing wrong current queue depth |
|
|
Disciple
Joined: 03 Oct 2017 Posts: 162
|
I am seeing a very strange issue here. I just connected to our QMGR using MQ explorer(Version: 8.0.0.2) and I saw curdepth greater than 0 in some of the queues. and then I ran MQSC command on the LINUX server (where our MQ is installed and I saw the same curdepth).
but when I right click on the queue in MQE and tried browsing the Queue, it gave me a message that there are no messages to browse (very strange), first i though the message got consumed in the meantime but I checked the LGETTIME on the Queue status and it was 1 day ago time.
How come the MQE and MQSC are showing curdepth GT 0 , if there are no messages, is there a defect , has anybody else notices it? |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Dec 28, 2018 7:11 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Expired messages and uncommitted messages both contribute to queue depth but are not messages that are visible when browsing the queue. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
PaulClarke |
Posted: Fri Dec 28, 2018 7:17 am Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
As Peter says......the most likely situation, of course, is that you have an application which has put some messages but not yet committed them . Issue a command such as
Code: |
DIS QSTATUS(TEST) UNCOM |
to see whether there are any uncommitted messages on the queue.
Cheers,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
vicks_mq |
Posted: Fri Dec 28, 2018 7:34 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017 Posts: 162
|
PaulClarke wrote: |
As Peter says......the most likely situation, of course, is that you have an application which has put some messages but not yet committed them . Issue a command such as
Code: |
DIS QSTATUS(TEST) UNCOM |
to see whether there are any uncommitted messages on the queue.
Cheers,
Paul. |
Does uncommitted messages means the "Receiver listeners" won't be able to pick them?
also, I am not sure if they are uncommitted messages, there were in count of more than 4,500, an application will not keep so many uncommited message in queue.(and I have not seen that application has done it before, and no change has been done to that application).
my best guess is probably those messages were expired.
Is there a way to change the settings in MQE not to show expired message at all, as it creates confussion. |
|
Back to top |
|
 |
PaulClarke |
Posted: Fri Dec 28, 2018 7:39 am Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
Well, if they are expired messages then I would expect the count to correct itself if you try to actually consume the messages.
There is no way I know of not to have expired messages counted in the DIS QUEUE CURDEPTH output. The point is that the Queue Manager doesn't yet know that they are expired. The Queue Manager does have a scavenger thread that will soon or later notice that the messages are expired and clean up the queue but the other way is just to try and MQGET them.
Cheers,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
Vitor |
Posted: Wed Jan 02, 2019 6:35 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
vicks_mq wrote: |
Does uncommitted messages means the "Receiver listeners" won't be able to pick them? |
Yes, because the uncommitted status means the sending application hasn't finally decided to put them.
vicks_mq wrote: |
also, I am not sure if they are uncommitted messages, there were in count of more than 4,500, an application will not keep so many uncommited message in queue.(and I have not seen that application has done it before, and no change has been done to that application). |
Proves nothing in my cynical opinion. It's perfectly possible that the commit limit is a configuration value and can be altered without changing the actual code. Perhaps someone tried to change the value from 100 to 1000 and hit the 0 one too many times.
vicks_mq wrote: |
my best guess is probably those messages were expired. |
I would be very surprised if that was the case, especially if there's something reading the queue (like the "receiver listeners" you mention above). A read operation will automatically remove all the expired messages on the queue and if there's no such read, the scavenger process my worthy associate mentions will clean them up. You don't mention the OS that you're using but on a distributed platform it runs about every 30 minutes. This makes it unlikely that 4,500 expired messages have sat there for a day and the scavenger has run about 50 times without noticing these messages, so it's much more likely these are uncommitted messages.
vicks_mq wrote: |
Is there a way to change the settings in MQE not to show expired message at all, as it creates confussion. |
No, because they count towards queue depth, _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|