| Author |
Message
|
| mqdude70 |
 Posted: Fri Dec 05, 2003 9:31 am Post subject: Queue Depth and Actual messages differ |
 |
|
Apprentice
Joined: 13 Nov 2003
Posts: 28
|
Hi Guys,
I have a problem in reading mq. when I am verifying the depth using the client it says depth is 100. Once I read the messages it gives out only 40 messages and the queue is emptied. Am I missing somthing here? Both Java and C clients behave the same way.
_________________
Thanks,
-MQdude70 |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Fri Dec 05, 2003 9:39 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Most likely the other 60 messages were expired and they were not removed until there was a get performed.
Did this happen only once, if so, this is the cause. If not, then we might have to investigate further.
Cheers
Kumar |
|
| Back to top |
|
|
| mqdude70 |
| Posted: Fri Dec 05, 2003 9:53 am Post subject: |
|
|
Apprentice
Joined: 13 Nov 2003
Posts: 28
|
Hi Kumar thanks for the reply. It happens everytime. How do I verify the expiry? Im not sure in what units it is set what units it is set in the header? If I browse through capitalware's MQ visual Edit also it shows the same.. around 40( 39 or 40 or 41) I am confused!
_________________
Thanks,
-MQdude70 |
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri Dec 05, 2003 11:53 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| You can run the amqsbcg sample against the program to see what the expiry is set to. It is a period of time expressed in tenths of a second. -1 indicates unlimited. There are details in the MQMD section of the Application Programming Reference. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Dec 05, 2003 12:11 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Just wanted to add to what bower already mentioned. You can browse/get messages off the queue only if they are not expired. If the expiry interval elapsed, then there is no way you could look at the messages. They count towards the curdepth, but cannot be viewed/retrieved.
Hence your alternative would be to find out who(which app) is putting these messages and check the expiry on md of the put and accordingly design your get app, if needed.
Cheers
Kumar |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Dec 05, 2003 1:34 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
There is also the remote possibility that the mesages have been PUT under a syncpoint that has not yet been committed.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Dec 05, 2003 1:42 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Just to add to what eddie mentioned, there is that possibility, but the queue should show messages after the get ends. Unless the put backs out, or messages got by some other app, just in time after the put commits. So, yes, this is a possibility if the putter is backing out.
Cheers
Kumar |
|
| Back to top |
|
|
| mqdude70 |
| Posted: Fri Dec 05, 2003 1:44 pm Post subject: |
|
|
Apprentice
Joined: 13 Nov 2003
Posts: 28
|
Thanks for the reply guys! I see the expiry as 5500 so that it may be 550 seconds. some with -1 so it never expires. I am investigating thro all the options suggested. yet to arrive at the solution. The problem is the client that puts the message has no idea what they are doing. No use asking them. Just now I saw the depth as 600 and got only 42 messages. I am still trying to figure out...
_________________
Thanks,
-MQdude70 |
|
| Back to top |
|
|
| Glen Shubert |
| Posted: Fri Dec 05, 2003 1:52 pm Post subject: |
|
|
Apprentice
Joined: 16 May 2001
Posts: 42
Location: TSYS - Columbus, GA
|
Isn't 5500 expiry = 55 seconds. It is specified in milliseconds, not tenths.
_________________
Glen Shubert
Associate Director
MQSeries Technical Support
TSYS |
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri Dec 05, 2003 2:58 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
According to the Application Programming Reference:
| Quote: |
This is a period of time expressed in tenths of a second, set by the application that puts the message. The message becomes eligible to be discarded if it has not been removed from the destination queue before this period of time elapses.
|
|
|
| Back to top |
|
|
| mqdude70 |
| Posted: Fri Dec 05, 2003 3:43 pm Post subject: |
|
|
Apprentice
Joined: 13 Nov 2003
Posts: 28
|
I made an observation by reading messages one by one. When depth was 150 I started to read one bye one.
After 150
2nd time depth was 149
3rd time depth was 112
4th time depth was 75
5th time depth was 41
6th time depth was 40
7th time depth was 39
8th time depth was 37
9th time depth was 35
and so on..
(I found each message with expiry not in order.. kinda random expiry)
My theory is..
It might have had the expired messages in between and gets deleted as soon as one before that expired was read! Can someone tell me my analogy is right?
_________________
Thanks,
-MQdude70 |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Dec 05, 2003 6:12 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Yep, that would make sense. The expired message is deleted at the point it WOULD have been read or browsed (except z/OS).
That means that any message behind the one you actually got, could be expired, but still on the queue.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Linda Rusvelt |
| Posted: Mon Dec 22, 2003 7:01 am Post subject: |
|
|
Newbie
Joined: 22 Dec 2003
Posts: 2
|
Hi MqDude,
I used WMQTool to view all these information. It displays it very meaningfully. It is FREE and you can download it from www.niratul.com
Linda |
|
| Back to top |
|
|
|
|
