| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Channel interferring with Depth Trigger on TX Queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| ewilliams |
 Posted: Tue Dec 03, 2002 9:17 pm Post subject: Channel interferring with Depth Trigger on TX Queue |
 |
|
Apprentice
Joined: 27 Nov 2002
Posts: 30
Location: Portland
|
COMPONENTS: QMgr(Sun Unix) & QMgr(AS/400) Distributed Model (Vendor application isn't compatible with clustering yet!)
NEED: I want to know when a queue depth is reached on the transmission queue on unix. If messages starting queueing that would indicate problems with MQ Series(channels, listeners, etc), network problems, or queue processing applications for both the Unix and AS/400 envirments.
SOLUTION: I built a ksh script that will write some Unix/MQSC commands output to a email to be sent to admins - to be triggered by a depth queue event. The problem is that when the sender/reciver channels are running the IPPROC & OPPROCs for the Tx Queue incriment by 1 so that depth triggering isn't possible any more (according to documentation).
In addition I did test the script and it does work with a EVERY trigger type.
1. Is it normal for the procs to incriment when the channels are running, why?
2. Is there another method that I am overlooking for monitoring things of this nature?
Any suggestions or help is appreciated much!
laters
Eric |
|
| Back to top |
|
 |
| nimconsult |
| Posted: Tue Dec 03, 2002 11:13 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
1.
The channel agent is an MQ application that opens the transmission queue, so the proc counters are increased. In this case it is true that you cannot rely on triggering ti be alerted when a certain queue depth is reached.
2.
There are multiple solutions, even outside of acquiring a monitoring tool (many monitoring tools on the market can be customized to perform what you want).
As home made solution I would suggest:
a. perform queue depth monitoring by starting your script periodically. This is the most straightforward solution if we consider that you have already developped the script.
b. customize and enable the "queue depth high" event on the transmission queue and capture the event (using a standard tool, or by writing an event monitor of your own, listening on the SYSTEM.ADMIN.PERFM.EVENT).
You could also use other techniques than queue depth monitoring to detect anomalies. In fact if the throughput of your client applications is low, you will not realize that there is a problem over the network by monitoring the transmission queue depth only.
a. the most obvious one is the channel status.
b. transmission queue "service interval" is another interesting event
c. periodically browse the first message on the transmission queue, and compare the put time with the current time.
Nicolas
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| 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
|
|
|
|
