Author |
Message
|
elamide |
Posted: Thu Jan 13, 2011 10:36 am Post subject: automatic inhibitget |
|
|
Newbie
Joined: 13 Jan 2011 Posts: 3
|
Whenever we have a connection issue, even just a momentary failure, with a transmission queue it automatically has the Get permission set to inhibit. Is there anyway to not have this happen or have it automatically reset to allowed? |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 13, 2011 10:39 am Post subject: Re: automatic inhibitget |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
elamide wrote: |
Is there anyway to not have this happen |
No. The MCA does this and AFAIK it's not configurable.
elamide wrote: |
have it automatically reset to allowed? |
A better question is why would you want get enabled on a transmission queue routinely or at all? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
elamide |
Posted: Thu Jan 13, 2011 10:48 am Post subject: |
|
|
Newbie
Joined: 13 Jan 2011 Posts: 3
|
We have a service that checks it for stalled messages. It gets the first message, waits, checks if it still there, continues forever. This of course fails when the queue has get inhibited. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 13, 2011 10:55 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
elamide wrote: |
This of course fails when the queue has get inhibited. |
Why not check for queue depth? Flag persistent non-zero depth? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
elamide |
Posted: Thu Jan 13, 2011 11:08 am Post subject: |
|
|
Newbie
Joined: 13 Jan 2011 Posts: 3
|
The queues in question will usually have a non-zero depth due to message rates, this is fine as long as the messages in the queue are always moving out of the queue. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 13, 2011 11:12 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
elamide wrote: |
The queues in question will usually have a non-zero depth due to message rates, this is fine |
Either you have some very, very high message rates, very, very big messages or your network sucks.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
mvic |
Posted: Thu Jan 13, 2011 12:15 pm Post subject: |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
Some ideas:
Check channel status instead. (DISPLAY CHSTATUS)
Or use the qmgr error logs and look for channel errors in there.
Channels tend to open their xmitq exclusively (I thought..) so am surprised you can get a browser to open the queue successfully.
If your browser fails because of get(disabled) condition, isn't this a sure sign there is a problem. So, mission accomplished, the app found a problem. ? |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Jan 13, 2011 12:30 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Get-inhibiting a transmission queue when the channel fails is normal behavior for an MCA. When the channel starts again, the queue will be get-enabled by the MCA.
Working as designed and documented. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
ivanachukapawn |
Posted: Wed Feb 10, 2016 8:43 am Post subject: |
|
|
 Knight
Joined: 27 Oct 2003 Posts: 561
|
My MQ 7.5.0.5 QM (Linux) is setting SYSTEM.ADMIN.CHANNEL.EVENT to inhibitGet and then setting it back to get enabled. Queue depth on this queue is 0 - and I don't know of any app which would dequeue its messages.
I know queue depth is not the issue, just providing this extraneous info.
Is there some automatic MCA inhibitGet-setting-activity for a non-XMIT queue, like SYSTEM.ADMIN.CHANNEL.EVENT ? |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Feb 10, 2016 9:06 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
ivanachukapawn wrote: |
My MQ 7.5.0.5 QM (Linux) is setting SYSTEM.ADMIN.CHANNEL.EVENT to inhibitGet and then setting it back to get enabled. Queue depth on this queue is 0 - and I don't know of any app which would dequeue its messages.
I know queue depth is not the issue, just providing this extraneous info.
Is there some automatic MCA inhibitGet-setting-activity for a non-XMIT queue, like SYSTEM.ADMIN.CHANNEL.EVENT ? |
How do you know that MQ is doing this? _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Feb 10, 2016 3:01 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
elamide wrote: |
We have a service that checks it for stalled messages. It gets the first message, waits, checks if it still there, continues forever. This of course fails when the queue has get inhibited. |
Just check Oldest Message Age. No need to get into the q to do that. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
ivanachukapawn |
Posted: Thu Feb 11, 2016 4:58 am Post subject: |
|
|
 Knight
Joined: 27 Oct 2003 Posts: 561
|
I don't have definitive proof that the get is inhibited on SYSTEM.ADMIN.CHANNEL.EVENT - we are using Hyperic (a Vmware monitoring product - this is a generalized monitoring product which does not have customization for MQ monitoring out of the box - for instance, it is incapable of monitoring for RETRYING cluster senders which have been auto-created) - Hyperic puts out an alert for a queue which is get inhibited - we get the alert (email) - the queue is not get inhibited any time I have looked at it - and it always has a queue depth of 0. I couldn't find any documentation indicating that MQ automatically sets get inhibited for any OTHER than XMIT queues. We have 2 MQ admins. Neither of us are setting get inhibited. We have 20 queue managers which are identically configured. Hyperic is emailing the get inhibited alert for only 1 of the QMs. I am beginning to think that it is just a Hyperic configuration error. |
|
Back to top |
|
 |
|