Author |
Message
|
murdeep |
Posted: Tue Jan 29, 2008 3:40 pm Post subject: RESET Q STATS shows HWM 1 but 0 enqueues |
|
|
Master
Joined: 03 Nov 2004 Posts: 211
|
Hi, I am puzzled by the following. We are running WMQ V6.0.2.1 on SunSolaris - SunOS 5.10.
We do a reset q stats every minute on select queues to watch activity. On one queue I see the following over four intervals:
Date|Time|Qmgr|Queue|ResetTime|ENQ|DEQ|HWM
1/29/2008|1:17:08 PM|QM1|Q1|59|0|0|0
1/29/2008|1:18:07 PM|QM1|Q1|59|0|0|1
1/29/2008|1:19:07 PM|QM1|Q1|60|0|1|1
1/29/2008|1:19:07 PM|QM1|Q1|60|0|0|0
How can the depth (HWM) in the interval 1:18:07 go to 1 with no enqueues? Is there some way to get a message on a queue that the statistics counters maintained by WMQ will not account for? I have my doubts. Please advise. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Jan 29, 2008 8:26 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
A q with one message on it.
Get the message under syncpoint. The q depth goes down to zero, the deque count goes up by one.
Roll the message back. The q depth goes up to one. The enqueu count stays zero.
 _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
murdeep |
Posted: Wed Jan 30, 2008 7:39 am Post subject: |
|
|
Master
Joined: 03 Nov 2004 Posts: 211
|
If that's the case then wouldn't I have seen an enqueue in interval 1:17:08? I should see an enqueue in some interval yet we don't.
Also, in this case as far as I know the application is not issuing any rollbacks. I'm looking into getting more info on the application to see if we can determine what it is doing that may be causing this. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Jan 30, 2008 1:08 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
hmmm, good point. I dunno.  _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
tleichen |
Posted: Wed Jan 30, 2008 2:25 pm Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005 Posts: 663 Location: Center of the USA
|
This is just a guess, but I suppose that the enqueue count in your display is not a cumulative count for the interval, but rather a snapshot of what is occurring at that instance.  _________________ IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jan 30, 2008 2:26 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
tleichen wrote: |
This is just a guess, but I suppose that the enqueue count in your display is not a cumulative count for the interval, but rather a snapshot of what is occurring at that instance.  |
RESET Q STATS is cumulative for the period of time since the last reset.
So one possibility is that something else is doing a reset in between two intervals as reported here - and the enqueue showed up in that view and not this one. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
tleichen |
Posted: Wed Jan 30, 2008 2:33 pm Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005 Posts: 663 Location: Center of the USA
|
Sounds feasible.  _________________ IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Jan 30, 2008 2:45 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
and also a much simpler explanation than mine on how the depth can go up by 1 with no (apparent) enqueue. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
murdeep |
Posted: Fri Feb 01, 2008 8:07 am Post subject: |
|
|
Master
Joined: 03 Nov 2004 Posts: 211
|
No other reset was being done. You can see that by analyzing the reset times and the timestamps.
In any case Peter's explanation is the winner. Turns out the app was doing a dequeue but never committing. After long periods of time it would fail and the message would reappear - that is why I didn't see the enqueue in an interval close to where the HWM suddenly appeared as 1 - the original enqueue happened in a previous interval. The backout doesn't count as an enqueue as Peter suggested but will result in a subsequent dequeue once the app runs again.
I determined this by watching the queue and when the HWM went back to one I amqsbcg'd the queue and saw the backout count was a large number. Application folks are now looking into why this is occurring. They also had an epiphany and are also adding some logging to their app so they can see what it is doing. |
|
Back to top |
|
 |
|