|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
XMITQ PUT_INHIBITED Automatically? |
« View previous topic :: View next topic » |
Author |
Message
|
Jeff.VT |
Posted: Sat Jul 18, 2020 8:15 am Post subject: XMITQ PUT_INHIBITED Automatically? |
|
|
Acolyte
Joined: 02 Mar 2017 Posts: 71
|
I've run into a rather odd issue, and I'm curious if another issue is related or if I'm chasing down a red herring.
QM1 has several dozen inbound 3rd party connections
QM2 has internal application connections
QM1 & QM2 are part of a Cluster: CLUSTER1
One of my 3rd parties has an issue where we keep receiving uncommitted messages from them. They'll back them out, and the system will run fine for a while, then we'll get uncommitted messages again after a couple hours. That's obviously an issue on their side. The uncommitted messages show up on my side on whatever queue I point their destination to (local, xmitq, doesn't matter).
Every time this week that this had occurred, we'd backed them out within 12 hours or so. But since it was the weekend, we hadn't backed them out recently. Today the Cluster Transmit queue for the QM1 > QM2 cluster sender channel spontaneously went to "PUT(INHIBITED)". This caused a massive ruckus & outage since those dozen inbound 3rd party connections all ALSO use that cluster sender channel. So my receiver channels for those connections went into PAUSED (first time I've ever seen that particular receiver channel status), and the messages all began going into DLQ.
----------
My question is this... Can uncommitted messages from a faulty sender/receiver pair cause a Cluster Transmit Queue to go into PUT(INHIBITED)? Is there a timer? like after 24 hours of uncommitted, it sets this value?
Or do you think the uncommitted messages and PUT(INHIBITED) unrelated?
I'm going to put in a ticket to IBM as well, but thought I'd cover all my bases. |
|
Back to top |
|
 |
bruce2359 |
Posted: Sat Jul 18, 2020 9:08 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
What errors did you see in the error logs in qmgrs at both ends of the channel? _________________ 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: Sat Jul 18, 2020 11:48 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
I have never seen MQ put inhibit a transmission queue. Get inhibit, yes, standard operating procedure. But put inhibit? Very strange. My suspicions lie with faulty automation tooling or faulty human operator decision making. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Jul 20, 2020 5:23 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
PeterPotkay wrote: |
I have never seen MQ put inhibit a transmission queue. Get inhibit, yes, standard operating procedure. But put inhibit? Very strange. My suspicions lie with faulty automation tooling or faulty human operator decision making. |
I would expect that once the XMITQ reached its max qdepth, and the channel has no DLQ, it might put inhibit the XMITQ.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Jul 20, 2020 5:49 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Nah. Put inhibiting an xmit queue would mask the queue-full condition. _________________ 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 |
|
 |
hughson |
Posted: Mon Jul 20, 2020 6:59 pm Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
fjb_saper wrote: |
I would expect that once the XMITQ reached its max qdepth, and the channel has no DLQ, it might put inhibit the XMITQ.  |
Nope. _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
hughson |
Posted: Mon Jul 20, 2020 7:08 pm Post subject: Re: XMITQ PUT_INHIBITED Automatically? |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
Jeff.VT wrote: |
One of my 3rd parties has an issue where we keep receiving uncommitted messages from them. They'll back them out, and the system will run fine for a while, then we'll get uncommitted messages again after a couple hours. That's obviously an issue on their side. The uncommitted messages show up on my side on whatever queue I point their destination to (local, xmitq, doesn't matter). |
Your description left me with the understanding that these messages are arriving on your queue manager via an MCA channel not a client channel - is this correct?
If yes, the 3rd party must have committed the messages before the sender channel can pick them up and move them to your queue manager. Therefore, if you have uncommitted messages on your queue manager, put there by a receiver channel, it is the channel, not something on the 3rd party queue manager, that isn't committing the messages.
Jeff.VT wrote: |
Every time this week that this had occurred, we'd backed them out within 12 hours or so. |
What operation do you do when you say "we'd backed them out"? Are you issuing a RESOLVE CHANNEL command?
Jeff.VT wrote: |
My question is this... Can uncommitted messages from a faulty sender/receiver pair cause a Cluster Transmit Queue to go into PUT(INHIBITED)? |
As many others have already said, no, MQ will not automatically change any queue to PUT(INHIBITED).
If you don't know what is causing the queue to be changed to PUT(INHIBITED), I suggest you turn on configuration events to discover who is doing it.
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
Jeff.VT |
Posted: Mon Aug 10, 2020 9:58 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017 Posts: 71
|
Thank you for the responses here.
Quote: |
What operation do you do when you say "we'd backed them out"? Are you issuing a RESOLVE CHANNEL command? |
The 3rd party did, yes.
It was a Receiver channel from a third party that was then directly routed to a remote queue that would go over a cluster channel. The cluster transmit queue is the queue that went into PUT(INHIBITED).
The only other thing I can think of is that the 'Max Uncommitted Messages' setting kicked in. I'm not sure what happens when it hits that max. The default is I think 10,000. And since the maximum number of concurrent uncommitted messages you should be able to have would be the maximum batch size for a channel, I would conclude that the "MaxUncommittedMessages" value is speaking about cumulative uncommitted messages. But I don't know the action it would do when it reaches that value.
And it's not like I can easily just create uncommitted messages so I can test any theory - before this issue I don't know that I've ever seen an uncommitted message before ever. Not even sure how I would go about making them.
----------------
Anyway - I think we have our answer. The IBM ticket is similarly confused as to what happened. I think the 3rd party has successfully found whatever application bug they have on their side that caused the uncommitted messages to begin with - and we might have discovered what we can do on our side to not prompt them.
But it was quite a roller coaster of emotion there for a few days.
Thanks![/quote] |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Aug 10, 2020 1:17 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Jeff.VT wrote: |
The only other thing I can think of is that the 'Max Uncommitted Messages' setting kicked in. I'm not sure what happens when it hits that max. The default is I think 10,000. |
Ok, so far.
Jeff.VT wrote: |
And since the maximum number of concurrent uncommitted messages you should be able to have would be the maximum batch size for a channel, I would conclude that the "MaxUncommittedMessages" value is speaking about cumulative uncommitted messages. But I don't know the action it would do when it reaches that value. |
No. MaxUncommittedMessages setting in the qmgr applies to a single UofW, and NOT all cumulative UofWs in the qmgr. BatchSize determines how many messages will be included in a batch send/received across a channel. Channel ends create new batches and new UofWs for those batches. These UofW's are unrelated to MQPUTting apps and their UofW's.
I've not seen an xmitq put(inhibited). _________________ 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 |
|
 |
|
|
 |
|
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
|
|
|
|