| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Get Inhibited |
« View previous topic :: View next topic » |
| Author |
Message
|
| rjl_state |
 Posted: Fri Nov 29, 2002 11:23 am Post subject: Get Inhibited |
 |
|
Apprentice
Joined: 04 Oct 2002
Posts: 48
Location: Des Moines, IA
|
I have written a program to monitor a transmit queue. It basically will browse for messages on the transmit queue, if any are found some information on them is saved (up to 200 messages), it then delays, and then does the same thing. If any messages are found, they are compared to the saved messages (if any), if they are the same message then there is a problem because messages are not going off the transmit queue like they should and my program reports the error.
This program was written as a backup to a monitoring tool we have purchased.
The problem I am having and wonder if anyone knows about is this: A couple of times when we have had problems and the sender channel goes into a retry state, the utility is taking error 2016, that the queue is get inhibited. I couldn't find anything in the manuals to explain this and wondered if anyone else could come up with an explination for this. 
Thanks in advance. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Nov 29, 2002 1:25 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
From Chapter 5 of the Intercommunication Handbook:
| Quote: |
Errors on channels cause the channel to stop further transmissions. If the channel is a sender or server, it goes to RETRY state because it is possible that the problem may clear itself. If it cannot go to RETRY state, the channel goes to STOPPED state. For sending channels, the associated transmission queue is set to GET(DISABLED) and triggering is turned off.
|
Seems to me you are doing a lot of extra work. Simply checking queue depth on an XMIT queue is enough to tell you if there is a problem. Almost always, that queue depth should be at or near zero. If you check queue depth every X minutes, and you see that it is climbing or staying above a certain threshhold, you can tell you have a problem.
When MQ channels are properly set up (using Triggering, DISCINT, Heartbeats, AdoptMCA, etc) they are pretty robust and as soon as the network comes back up, they will restart automatically.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| nimconsult |
| Posted: Sun Dec 01, 2002 11:33 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
An alternative is to browse the first message of the queue only, and compare the puttime of the message with the current time. If the interval is greater than a pre-defined value then the channel is too slow.
I think that it is much more efficient than storing 200 messages of the queue.
Nicolas
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| rjl_state |
| Posted: Mon Dec 02, 2002 4:53 am Post subject: |
|
|
Apprentice
Joined: 04 Oct 2002
Posts: 48
Location: Des Moines, IA
|
Thank you Peter and Nicolas for your responses. I agree with both of your suggestions.  |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Dec 03, 2002 8:31 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
You can also use the runmqsc trick to check if messages are flowing
echo dis chs(jdunn*) MSGS BYTSSENT STATUS| runmqsc QMGR_NAME > file.out
inside the file those fields will contain counts indicating if the channel is moving data, the only issue comes to play is from a disconnect interval
which will cause the counters to start over.
You can write a perl script /unix script to parse the info
NOTE: Bytes sent will go up every 5/10 minutes even if there is no data
in the xmitq to send !!!
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| mgrabinski |
| Posted: Wed Dec 04, 2002 10:12 pm Post subject: |
|
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
There's yet another method - good for request/reply scenario - it allows you to check if messages can flow in both directions.
Say you have two managers - QM1 and QM2
At QM1 define two queues:
| Code: |
DEF QR(QM1_QREMOTE) RQMNANE(QM1_ALIAS) RNAME(QM1_QLOCAL) XMITQ(QM2)
DEF QL(QM1_QLOCAL)
|
At QM2 define a manager alias:
| Code: |
DEF QR(QM1_ALIAS) RQMNAME(QM1)
|
Those definitions (plus XMIT queues and channels) make it possible to check if a message send from QM1 to QM2 (via QM1_QREMOTE) can be returned back to QM1. If include put time in the message application data part, you will also have an idea of the current response time.
_________________
Marcin Grabinski <>< |
|
| 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
|
|
|
|
