| Author |
Message
|
| PeterPotkay |
 Posted: Mon Nov 19, 2007 10:26 am Post subject: Expired Messages and MsgDeqCount |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
MQ 6.0.2.1
Put 10 messages on a queue with 5 minute expiry. Then repeatedly browse the queue during the first 5 minutes. MsgDeqCount does not go up. So far so good. After 5 minutes go by the messages expire. Do another browse. MsgDeqCount is now 10. Huh? Or even better, repeat the test but once the messages expire just wait 5 or so minutes more and let MQ 6.0's built in Expiry Scavenger do its thing. Again MsgDeqCount goes up to 10.
Is this expected behavior? An expired message can never be returned to an app so how/why would it drive MsgDeqCount?
MsgDeqCount is getting less useful as a metric I feel. With the above scenario you could have a queue that reports big numbers for MsgDeqCount when in fact no messages were returned to the app. Right next to it you could have another queue where the putter and getter are exchanging lots of messages outside of syncpoint while both have the queue open concurrently and MsgDeqCount reports zero (as long as the getter has an outstanding MQGET with Wait).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Mon Nov 19, 2007 12:06 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
| rxm8778 |
| Posted: Mon Nov 19, 2007 12:46 pm Post subject: |
|
|
Apprentice
Joined: 15 Sep 2005
Posts: 37
|
This has always been my understanding of expired messages: (at least in version 5.3)
messages that are set to expire after a certain amount of time, in your case 5 minutes, will not leave the queue on their own. They sit on the queue until an application actually attempts to perform an MQGET to retrieve those messages. Only at this point will they be retrieved from the queue. They will however not be delivered to the consuming application since they were marked expired. In that case I could see why it made sense that the deqcount went up. But it would still be a little misleading in a report since these message were expired and not truly processed by the application.
In your case where message are just moving out of the queue on their own after they expire without the invocation of a message consumer, I have not come accross this. Could it be some Version 6 new functionality????
And yes...the particular scenario your ran accross (expired messages vanishing from the queue and increasing the dequeue count without the use of a consuming application) would make the deqcount a number that can no longer be trusted.....
Last edited by rxm8778 on Mon Nov 19, 2007 12:51 pm; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Nov 19, 2007 12:50 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| rxm8778 wrote: |
| In your case where message are just moving out of the queue on their own after they expire without the invocation of a message consumer, I have not come accross this. Could it be some Version 6 new functionality???? |
That is new V6 functionality and I know why they are being flushed from the queue. Its a good thing. What's misleading is the MsgDeqCount goes up for each message that expires off of the queue.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| markt |
| Posted: Mon Nov 19, 2007 1:03 pm Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
I assume you're referring to the numbers returned from RESET QSTATS.
It seems quite reasonable that this shows the number of messages removed from a queue - how they are removed shouldn't be relevant. The messages have certainly been dequeued, albeit by the system.
If you want greater detail, such as how many messages are removed by specific apps, then you've got the accounting events in V6.
And the statistics events show how many messages expired. |
|
| Back to top |
|
|
|
|
