ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportXMITQ PUT_INHIBITED Automatically?

Post new topicReply to topic
XMITQ PUT_INHIBITED Automatically? View previous topic :: View next topic
Author Message
Jeff.VT
PostPosted: Sat Jul 18, 2020 8:15 am Post subject: XMITQ PUT_INHIBITED Automatically? Reply with quote

Acolyte

Joined: 02 Mar 2017
Posts: 55

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
View user's profile Send private message
bruce2359
PostPosted: Sat Jul 18, 2020 9:08 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8811
Location: US: west coast, almost. Otherwise, enroute.

What errors did you see in the error logs in qmgrs at both ends of the channel?
_________________
My life flows on in endless song;
How can I keep from singing?
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Sat Jul 18, 2020 11:48 am Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7631

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
View user's profile Send private message
fjb_saper
PostPosted: Mon Jul 20, 2020 5:23 am Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20419
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
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Mon Jul 20, 2020 5:49 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8811
Location: US: west coast, almost. Otherwise, enroute.

Nah. Put inhibiting an xmit queue would mask the queue-full condition.
_________________
My life flows on in endless song;
How can I keep from singing?
Back to top
View user's profile Send private message
hughson
PostPosted: Mon Jul 20, 2020 6:59 pm Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1512
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
View user's profile Send private message Visit poster's website
hughson
PostPosted: Mon Jul 20, 2020 7:08 pm Post subject: Re: XMITQ PUT_INHIBITED Automatically? Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1512
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
View user's profile Send private message Visit poster's website
Jeff.VT
PostPosted: Mon Aug 10, 2020 9:58 am Post subject: Reply with quote

Acolyte

Joined: 02 Mar 2017
Posts: 55

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
View user's profile Send private message
bruce2359
PostPosted: Mon Aug 10, 2020 1:17 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8811
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).
_________________
My life flows on in endless song;
How can I keep from singing?
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportXMITQ PUT_INHIBITED Automatically?
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.