| Author |
Message
|
| ayanc |
 Posted: Thu Jun 02, 2005 4:53 am Post subject: An interesting case |
 |
|
Voyager
Joined: 15 Nov 2004
Posts: 88
|
Hi All,
An interesting situation:
dis ql(ACCOUNT.TEST)
1 : dis ql(ACCOUNT.TEST)
AMQ8409: Display Queue details.
DESCR(Account Testing) PROCESS( )
BOQNAME( ) INITQ( )
TRIGDATA( ) CLUSTER( )
CLUSNL( ) QUEUE(ACCOUNT.TEST)
CRDATE(2005-05-26) CRTIME(05.19.24)
ALTDATE(2005-05-26) ALTTIME(05.19.24)
GET(ENABLED) PUT(ENABLED)
DEFPRTY(0) DEFPSIST(NO)
MAXDEPTH(5000) MAXMSGL(4194304)
BOTHRESH(0) SHARE
DEFSOPT(SHARED) HARDENBO
MSGDLVSQ(PRIORITY) RETINTVL(999999999)
USAGE(NORMAL) NOTRIGGER
TRIGTYPE(FIRST) TRIGDPTH(1)
TRIGMPRI(0) QDEPTHHI(80)
QDEPTHLO(20) QDPMAXEV(DISABLED)
QDPHIEV(DISABLED) QDPLOEV(ENABLED)
QSVCINT(999999999) QSVCIEV(NONE)
DISTL(NO) NPMCLASS(NORMAL)
DEFTYPE(PREDEFINED) TYPE(QLOCAL)
SCOPE(QMGR) DEFBIND(OPEN)
IPPROCS(2) OPPROCS(2)
CURDEPTH(7448)
Note the curdepth and maxdepth values.
Any idea about what is happening?
 |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Thu Jun 02, 2005 5:07 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| For curiosity's sake, did you actually run amqsbcg against the queue to see how many messages it found? I'd be interested in knowing if the curdepth count was actually accurate. |
|
| Back to top |
|
|
| ayanc |
| Posted: Thu Jun 02, 2005 5:24 am Post subject: |
|
|
Voyager
Joined: 15 Nov 2004
Posts: 88
|
Hi,
No in fact I didn't. However I monitored the queue continuosly using MQExplorer.
The queue depth was 10000 within an instant .... yes in an instant because just before that there were 1100 messages which were being dumped. When I wanted to see the curdepth (expectin to be 0) I found it to be 10000 instead.
I monitored the queue and found the queue to be decreasing steadily. |
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Thu Jun 02, 2005 5:26 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
| Only a wild guess, but could it be that there are uncommited messages that cause the CURDEPTH be more than the MAXDEPTH? |
|
| Back to top |
|
|
| ayanc |
| Posted: Thu Jun 02, 2005 5:27 am Post subject: |
|
|
Voyager
Joined: 15 Nov 2004
Posts: 88
|
Hey,
Just check this out:
MQGET of message number 7207
****Message descriptor****
StrucId : 'MD ' Version : 2
...
PutApplName : 'MQSeries Client for Java '
.........
So, the curdepth count isnt incorrect after all.....  |
|
| Back to top |
|
|
| mqmhr |
| Posted: Thu Jun 02, 2005 5:35 am Post subject: |
|
|
Centurion
Joined: 28 Dec 2004
Posts: 105
|
From the AP Reference
| Quote: |
| 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. |
Are you able to correlate this with your scenario? |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Jun 02, 2005 6:10 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
mhhh i liked to confuse my studends with something like this when i held a mqseries administration course. Maybe the maxdepth was 10000 before and someone changed it to 5000 after the messages where put?
_________________
Regards, Butcher |
|
| Back to top |
|
|
| ayanc |
| Posted: Thu Jun 02, 2005 8:05 pm Post subject: |
|
|
Voyager
Joined: 15 Nov 2004
Posts: 88
|
Hi Butcher,
No that is not the case here. I have created the queue and set the maxdepth as 5000. The application teams dont have access rights to change the queue depth.
However I think sebastian and mqmhr may be correct. |
|
| Back to top |
|
|
|
|
