| Author |
Message
|
| tango |
 Posted: Thu Nov 19, 2009 3:25 am Post subject: Depth Trigger on SYSTEM.JMS.ND.SUBSCRIBER.QUEUE? |
 |
|
Apprentice
Joined: 14 Mar 2007
Posts: 42
|
Can a depth trigger be applied to SYSTEM.JMS.ND.SUBSCRIBER.QUEUE?
I've set up triggering on depth for SYSTEM.JMS.ND.SUBSCRIBER.QUEUE to clear the queue down before it reaches max depth. INITQ is SYSTEM.DEFAULT.INITIATION.QUEUE and this triggers a process which calls this script:
# Get messages from queue using qload utility.
/opt/mqm/bin/qload -m QMGR -I SYSTEM.JMS.ND.SUBSCRIBER.QUEUE
# Reset depth trigger.
echo "alter ql(SYSTEM.JMS.ND.SUBSCRIBER.QUEUE) TRIGGER"|runmqsc QMGR
It doesn't work against SYSTEM.JMS.ND.SUBSCRIBER.QUEUE but does work for local queues I've created.
Any ideas? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Nov 19, 2009 6:24 am Post subject: Re: Depth Trigger on SYSTEM.JMS.ND.SUBSCRIBER.QUEUE? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tango wrote: |
| I've set up triggering on depth for SYSTEM.JMS.ND.SUBSCRIBER.QUEUE to clear the queue down before it reaches max depth. |
This seems an odd way of dealing with a full queue, especially a SYSTEM one. What's the requirement here?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tango |
| Posted: Thu Nov 19, 2009 7:01 am Post subject: |
|
|
Apprentice
Joined: 14 Mar 2007
Posts: 42
|
We found that previous versions of MQ (we're on 7.0.1.0 now) didn't detect stale ND subs very quickly and the SYSTEM.JMS.ND.SUBSCRIBER.QUEUE fills up several times a day. A high QDepth here was a bit of a performance hit on pub/sub back when we were on Solaris. We're now on updated hardware so it's not so much of an issue (and setting a lower DurableSubMgrFrequency in v7 also seems to help).
The requirement is to prevent the SYSTEM.JMS.ND.SUBSCRIBER.QUEUE from reaching max-depth as it still can do once or twice a day. At present we have a java app configured to monitor for QDepth high events but I want to simplify this into a depth trigger.
Although we're running v7 Server, clients are still on v6. The above probably won't be required if/when they move to v7 client libs. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Nov 19, 2009 11:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tango wrote: |
| We found that previous versions of MQ (we're on 7.0.1.0 now) didn't detect stale ND subs |
I'm forced to ask why you have so many stale subscriptions (rhetorically) and if you've mentioned this to the application teams.
I would suspect there's something in the queue manager that's trying to protect the SYSTEM queue, or at least not expecting a trigger that the queue manager isn't setting itself.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tango |
| Posted: Fri Nov 20, 2009 1:43 am Post subject: |
|
|
Apprentice
Joined: 14 Mar 2007
Posts: 42
|
| max-depth of SYSTEM.JMS.ND.SUBSCRIBER.QUEUE currently set at 100k. It can hit that perhaps once or twice a week (was per day not so long ago). Yes app teams know and we're working to reduce this further. But in the meantime the auto clear down of this queue is still inplace when it reaches a certain level. I guess once or bi-weekly cleardown isn't too bad for a queue with an enqueue rate of 200k/min and 500+ subs at any given time. Thanks for your help. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 20, 2009 10:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| tango wrote: |
| max-depth of SYSTEM.JMS.ND.SUBSCRIBER.QUEUE currently set at 100k. It can hit that perhaps once or twice a week (was per day not so long ago). Yes app teams know and we're working to reduce this further. But in the meantime the auto clear down of this queue is still inplace when it reaches a certain level. I guess once or bi-weekly cleardown isn't too bad for a queue with an enqueue rate of 200k/min and 500+ subs at any given time. Thanks for your help. |
I'd say you need a better design.
Have each subscriber specify in the subscription a delivery queue for the subscription... You may have to create the aliases here as SYSTEM.JMS.ND.WHATEVER... This way you can have a real application queue be the target queue. You would also see much faster who the potential subscriber is that got disconnected and have the subscription be removed by some type of admin script?? And at the same time force a channel stop / restart on the app's TCF??
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
