| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Current Depth = 1 with no Msg availavle |
« View previous topic :: View next topic » |
| Author |
Message
|
| huebi |
 Posted: Tue Oct 22, 2002 4:58 am Post subject: Current Depth = 1 with no Msg availavle |
 |
|
Novice
Joined: 01 Jul 2001
Posts: 16
|
Sometimes i get a current depth = 1, input count = 1 and output count = 1. Msg Browse gives 2033 = no Message available and there is definitely no Application with open input/open output.
How can i clean up this situation? |
|
| Back to top |
|
 |
| Ophir Yoktan |
| Posted: Tue Oct 22, 2002 7:35 am Post subject: |
|
|
Novice
Joined: 15 Nov 2001
Posts: 20
Location: Israel
|
There are probably uncommited messages on the queue.
I don't know of any way to verify this in older versions, but MQS 5.3 has a command "dis qstatus(QUEUE)" which will help. |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Oct 22, 2002 11:25 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Either the message is uncommited, or is part of a MQSeries group or sequence which is not complete. However, if it is the latter case, you can always recode your application to get groups or sequences before they are complete. But if the message is uncommitted, there is nothing you can do programmatically. However, if this is the case, when the application put the message, the system was configured to either commit or rollback the unit of work in the case that it is not completed successfully. Since the message is still uncommitted, this would lead me to believe the putting application is still connected to the queue somehow. But since you are saying this is NOT the case, then my only thought would be to recycle the queue manager.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Thu Oct 31, 2002 7:12 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
In this case it is reading the queue that causes the message to actually expire. If you have report options for expiration selected it would be at this stage that a report was produced.
What you are seeing is how it should work. 
Cheers,
Vicky |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Oct 31, 2002 12:00 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Yes. The MQSeries documentation points out that expired messages aren't removed from the queue, until an MQGET is performed which would otherwise retrieve that particular message. That get returns a 2033, and the message is removed. "dis ql(*)" tells you whats in each queue without actually performing an MQGET, so it is able to "see" expired messages without causing them to go away. It's kinda like one of those "if a tree falls in a forest and nobody is around" type questions 
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| 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
|
|
|
|
