| Author |
Message
|
| kd |
 Posted: Wed Aug 16, 2006 4:18 am Post subject: browse failing on xmitq |
 |
|
Novice
Joined: 10 Aug 2006
Posts: 19
|
Hi,
I am writing a monitoring app for a 5.3 installation. I need to get the oldest messages on my queues, this is working fine by opening for browse and getting the puttime of the first message...
My problem is my sdr channels have a discint set, and so when they intermittently restart, my xmit queues go back to get(inhibited), and my browse fails.
Is there anything else I can do to browse these messages bar having a process constantly modifying the xmitq?
Thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Aug 16, 2006 4:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If there's any message on an xmitq that's a problem. Don't check date check depth!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 16, 2006 4:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If there are messages on the xmitq, then the channel may just be running slow.
It's not worth your time to write your own monitoring software, unless you intend to enter the montioring software market as a new vendor.
There are some simple monitoring things that can be programmed by anyone, and will work okay. But as the requirements grow from anything more than just "let me know if it's broken", then you rapidly leave the cost/benefit curve for in-house software. Proper monitoring of WebSphere MQ is a COTS problem, not a bespoke problem. Does your company pay you to be an MQ monitoring software expert? Or an expert in something else?
In v6.0, you can get statistics on message ages.
In most cases, if you want to monitor aspects of messages, it is best to use an API exit and track the messages as they move, rather than using browse. API exits are complicated.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 16, 2006 4:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
If there are messages on the xmitq, then the channel may just be running slow.
|
Which can be considered a problem, certainly if it persists.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kd |
| Posted: Wed Aug 16, 2006 4:41 am Post subject: |
|
|
Novice
Joined: 10 Aug 2006
Posts: 19
|
| Vitor wrote: |
| If there's any message on an xmitq that's a problem. Don't check date check depth! |
I am checking depth, however if there is a batch (say 10000 msgs) all at once, my depth threshold will alarm, but knowing also that the age of the first message is only 1 minute will allow the user to see that it's a batch and not a gradual build-up of messages which would indicate a problem.
Thanks |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 16, 2006 4:47 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Vitor wrote: |
| jefflowrey wrote: |
If there are messages on the xmitq, then the channel may just be running slow.
|
Which can be considered a problem, certainly if it persists. |
I'd argue that it's a problem only if it persists. Any channel is going to have messages backed up on its XMITQ if an application suddenly dumps 1,000,000 messages.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 16, 2006 4:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kd wrote: |
| Vitor wrote: |
| If there's any message on an xmitq that's a problem. Don't check date check depth! |
I am checking depth, however if there is a batch (say 10000 msgs) all at once, my depth threshold will alarm, but knowing also that the age of the first message is only 1 minute will allow the user to see that it's a batch and not a gradual build-up of messages which would indicate a problem.
Thanks |
Well yes, I conceed defeat on this point 
What I was getting at was that any sustained depth on an xmitq indicates a problem. Hence if you check it and there are 10,000 messages on it, the next check 5 minutes later should show considerably less. If that check shows high depth then either the channel has stopped or as jefflowrey correctly suggested it's running slow. Slow running is of course subjective and may not be a problem.
If anyone needs me, I'll be over here in the corner. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 16, 2006 4:49 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Kd -
You may have better luck monitoring this kind of "depth but nothing's wrong" situation by using RESET QUEUE STATISTICS and looking at the dequeue rate...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kd |
| Posted: Wed Aug 16, 2006 4:55 am Post subject: |
|
|
Novice
Joined: 10 Aug 2006
Posts: 19
|
| jefflowrey wrote: |
| You may have better luck monitoring this kind of "depth but nothing's wrong" situation by using RESET QUEUE STATISTICS and looking at the dequeue rate... |
Isn't that an MQv6 feature? I'm stuck with 5.3.11 at the mo... |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 16, 2006 5:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No. Reset Queue Statistics is in v5.3. You have to send it as a PCF command.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Aug 16, 2006 5:22 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
My problem is my sdr channels have a discint set, and so when they intermittently restart, my xmit queues go back to get(inhibited), and my browse fails.
|
I don't belive Discint should have anything to do with the XMIT queue going to get inhibited. If the channels are correctly triggered then no action is needed on the XMITQ. The fact that it is going get inhibited is usually cause by a Q full problem on the remote end. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 16, 2006 5:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I think it is normal operation of the channel to set the xmitq to get-inhibited, to ensure that nobody plays around with him while he's working.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
