| Author |
Message
|
| MCardinal |
 Posted: Fri Dec 03, 2010 7:46 am Post subject: Queue Inhibited on browse |
 |
|
Novice
Joined: 06 Oct 2010
Posts: 18
Location: Ottawa, Canada
|
Hi,
Just as a quick background, working with Websphere MQ 7 on Windows Server 2003, I made a monitoring tolls that check all queue of type local. It ran without any problem for a long time and I got this morning a message saying I got an error, MQRC_GET_INHIBITED on a transmit queue, while doing a browse command.
I would like ot know what may have caused this error to happen? The application continued and resumed correctly after. Nobody changed the queue definition or attribute. |
|
| Back to top |
|
 |
| zpat |
| Posted: Fri Dec 03, 2010 8:21 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| The channel does this automatically. I've never quite understood why because if you change it to get allowed, everything still works fine. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 03, 2010 9:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| I've never quite understood why because if you change it to get allowed, everything still works fine. |
AFAIK it's to stop messages that have been accepted for delivery being accidently read off by something other than the MCA and ruining WMQ's reputation for assured delivery.
Any IBMer is welcome to correct me.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 03, 2010 9:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
| zpat wrote: |
| I've never quite understood why because if you change it to get allowed, everything still works fine. |
AFAIK it's to stop messages that have been accepted for delivery being accidently read off by something other than the MCA and ruining WMQ's reputation for assured delivery.
Any IBMer is welcome to correct me. |
Because you or any process you create other than the channel agent has no business reading or browsing from the XMITQ.
Now should you (the admin) have a serious problem with the channel you may "get" enable the queue, to help troubleshoot, with the caveat Vitor specified. [no I am not working for IBM] 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Dec 03, 2010 10:08 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| fjb_saper wrote: |
| Vitor wrote: |
| zpat wrote: |
| I've never quite understood why because if you change it to get allowed, everything still works fine. |
AFAIK it's to stop messages that have been accepted for delivery being accidently read off by something other than the MCA and ruining WMQ's reputation for assured delivery.
Any IBMer is welcome to correct me. |
Because you or any process you create other than the channel agent has no business reading or browsing from the XMITQ.
Now should you (the admin) have a serious problem with the channel you may "get" enable the queue, to help troubleshoot, with the caveat Vitor specified. [no I am not working for IBM] |
Sometimes the channel is stopped for a good reason and people want to know what is waiting on the xmit queue.
I would have though MQ security controls could be used to protect the queue from message removal.
The xmit queue is not an internal feature of MQ, it's entirely exposed and documented and so I disagree that it should not be inspected. |
|
| Back to top |
|
|
| MCardinal |
| Posted: Fri Dec 03, 2010 10:09 am Post subject: |
|
|
Novice
Joined: 06 Oct 2010
Posts: 18
Location: Ottawa, Canada
|
My network environment is particular this is why I monitor the XMITQ. don't want to get too much in detail over this as it's not related to the subject.
Vitor's answer provided me with a reasonable approach that somehow couldn't figured out myself! After one month of running my app, I got this error, only once, so I guess this was only a coincidence of timing that I was browsing at the same time as the MCA. I will start to monitor this error message in a different way.
Thank You |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 03, 2010 10:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MCardinal wrote: |
| My network environment is particular this is why I monitor the XMITQ. don't want to get too much in detail over this as it's not related to the subject. |
It's not unreasonable to check the depth of a transmission queue; a growing depth is a omen of a number of problems and the depth of transmission queues should be a standard check on all installations.
What's less common is to check the depth by browsing the messages; partly for the problem you've found but mostly because browsing is hideously inefficient.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MCardinal |
| Posted: Fri Dec 03, 2010 10:59 am Post subject: |
|
|
Novice
Joined: 06 Oct 2010
Posts: 18
Location: Ottawa, Canada
|
I get your point Vitor for that I will honestly reply that I was too lazy to program different function if it's a transmit queue or regular local queue.
I will update it later on.
  |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 03, 2010 11:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MCardinal wrote: |
| I get your point Vitor for that I will honestly reply that I was too lazy to program different function if it's a transmit queue or regular local queue. |
My comments apply equally to local queues and transmit queues because they're both local queues. What makes a transmit queue a transmit queue is how the queue manager views it.
So the same function can check both. And that function should not use browsing. Because it's hideously inefficient, especially when you're browsing the entire queue to determine how many messages are in it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Dec 03, 2010 11:56 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| ...Because it's hideously inefficient, especially when you're browsing the entire queue to determine how many messages are in it. |
Which may change during the browsing operation, upwards in number or down...what's wrong with an inquire and extracting the queue depth?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 03, 2010 12:14 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| Which may change during the browsing operation, upwards in number or down...what's wrong with an inquire and extracting the queue depth? |
Another reason it's a bad idea.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 03, 2010 12:53 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| MCardinal wrote: |
| After one month of running my app, I got this error, only once, so I guess this was only a coincidence of timing that I was browsing at the same time as the MCA. |
You got the error because the MCA was NOT looking in the XMITQ at that time. The channel was most likely in a retry, during which time the XMITQ is get inhibited while the MCA is twiddling its thumbs waiting for the retry interval to go by.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
