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 IndexClusteringMQINQ and Clusters and needing to give too much access

Post new topicReply to topic
MQINQ and Clusters and needing to give too much access View previous topic :: View next topic
Author Message
PeterPotkay
PostPosted: Thu Oct 24, 2013 7:22 am Post subject: MQINQ and Clusters and needing to give too much access Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

Before I open an RFE to ‘fix’ this I wanted to see if any of you knew what the use case was to require MQ to work this way.


http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.dev.doc/q027050_.htm?resultof=%22%4d%51%49%4e%51%22%20%22%6d%71%69%6e%71%22%20%22%63%6c%75%73%74%65%72%22%20


Basically this link says that unless you add the option of Browse, Set, Output or Input to your MQOPEN call for a subsequent MQINQ (where you are specifying the MQOO_INQUIRE option already), “successive MQINQ calls might inquire on different instances of the cluster queue.”

Now why in the world would anyone connect to QMx to inquire about a queue on QMx and want to get results from random instances of that queue in the cluster? And only a subset of the attributes you could get if it was the local instance?

I am forced to give the UserID used by my little monitoring app more than I think it needs. All it needs is +inq, but I have to add +put, +set, +get or +browse. This is not good as now this ID, that only needs to execute an occasional MQINQ call, needs the ability to read application data, or consume app data, or insert its own messages, or PUT disable the queue.

My RFE would be for IBM to not require these extra authorizations. If the QM sees an MQOPEN call with only MQOO_INQUIRE come in against queue, assume the user wants information about the local instance of that queue and ‘bind’ all future MQINQ calls using that handle to the local instance of the queue. If there is no local instance of the queue hosted on that QM, the MQOPEN call should fail.

Is there a legitimate use case for getting a subset of attributes from some random instance of a queue in the cluster? If not, I think an RFE is warrented.


(No, I am not going to rewrite my app to use PCF messages. This question is all about the behavior of the MQINQ call and clustered queues.)
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Oct 24, 2013 8:38 am Post subject: Reply with quote

Poobah

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

http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/index.jsp?topic=%2Fcom.ibm.mq.dev.doc%2Fq027050_.htm&resultof%3D%2522%254d%2551%2549%254e%2551%2522%2520%2522%256d%2571%2569%256e%2571%2522%2520%2522%2563%256c%2575%2573%2574%2565%2572%2522%2520 says this at the bottom:
Quote:
Note: If you open a cluster queue without fixing the queue that MQOPEN has bound to, successive MQINQ calls might inquire on different instances of the cluster queue.

This indirectly addresses your question about a use case for the resolved (you said random) cluster queue. It is possible that a BIND_NOT_FIXED instance might become unavailable after MQOPEN. I suppose a new warning R/C might be more informative for this situation, like: MQRC_NEW_CLUSTER_QUEUE_INSTANCE.
_________________
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
View user's profile Send private message
PeterPotkay
PostPosted: Thu Oct 24, 2013 8:57 am Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

Yeah, but why would you ever issue an MQINQ call against QueueA connected to QM1 and then want a response that shows some but not all of the possible MQINQ values for QueueA on QM2, then QueueA on QM99, then QueueA on QM45 and occasionally for QueueA on QM1, in which case for that one instance you would get extra attributes returned (like qdepth)

It seems like a flaw to me for MQ to behave like this, and a security gap to require the user to grant authority to the MQINQer that allows them to change queues or mess with data in queues to get around the flaw.

I agree the behaviour is well documented. I'm saying the behaviour makes no sense, but maybe I'm missing something.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Oct 24, 2013 9:16 am Post subject: Reply with quote

Poobah

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

PeterPotkay wrote:
Yeah, but why would you ever issue an MQINQ call against QueueA connected to QM1 and then want a response that shows some but not all of the possible MQINQ values for QueueA on QM2, then QueueA on QM99, then QueueA on QM45 and occasionally for QueueA on QM1, in which case for that one instance you would get extra attributes returned (like qdepth) ...


PeterPotkay wrote:

I agree the behaviour is well documented. I'm saying the behaviour makes no sense, but maybe I'm missing something.

Hmmm... An app might want/need to know more about the resolved cluster queue. It is possible for other instances of a cluster queue to have different attribute values - especially as attributes change, and are advertised around the cluster.
_________________
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
View user's profile Send private message
PeterPotkay
PostPosted: Thu Oct 24, 2013 9:23 am Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

According to the doc, the hosting QM is not returned in the results of the MQINQ call. And you can't specify which remote instance you care about.

So the results you get aren't very useful. Issue MQINQ 10 times in a row and get back 6 differnet results and 4 of the same. Which 6 are the different ones? Are the 4 same ones 4 instances of the q that are defined the same, or did you get results 4 times for the same instance?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Thu Oct 24, 2013 3:04 pm Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

PeterPotkay wrote:
According to the doc, the hosting QM is not returned in the results of the MQINQ call. And you can't specify which remote instance you care about.

So the results you get aren't very useful. Issue MQINQ 10 times in a row and get back 6 differnet results and 4 of the same. Which 6 are the different ones? Are the 4 same ones 4 instances of the q that are defined the same, or did you get results 4 times for the same instance?

Aren't all instances of a clustered queue supposed to have the same attribute values that are visible to the cluster? Queue Managers generate messages in the error log if they aren't the same.
_________________
Glenn
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Oct 24, 2013 6:09 pm Post subject: Reply with quote

Poobah

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

gbaddeley wrote:
PeterPotkay wrote:
According to the doc, the hosting QM is not returned in the results of the MQINQ call. And you can't specify which remote instance you care about.

So the results you get aren't very useful. Issue MQINQ 10 times in a row and get back 6 differnet results and 4 of the same. Which 6 are the different ones? Are the 4 same ones 4 instances of the q that are defined the same, or did you get results 4 times for the same instance?

Aren't all instances of a clustered queue supposed to have the same attribute values that are visible to the cluster? Queue Managers generate messages in the error log if they aren't the same.


Examples where attributes might differ: One instance of the queue is full or put/get inhibited. Nothing on error logs.
_________________
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
View user's profile Send private message
PeterPotkay
PostPosted: Fri Oct 25, 2013 5:09 am Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

gbaddeley wrote:
PeterPotkay wrote:
According to the doc, the hosting QM is not returned in the results of the MQINQ call. And you can't specify which remote instance you care about.

So the results you get aren't very useful. Issue MQINQ 10 times in a row and get back 6 differnet results and 4 of the same. Which 6 are the different ones? Are the 4 same ones 4 instances of the q that are defined the same, or did you get results 4 times for the same instance?

Aren't all instances of a clustered queue supposed to have the same attribute values that are visible to the cluster? Queue Managers generate messages in the error log if they aren't the same.


These are the only attributes you will get results on if the instance of the queue the MQINQ happens to get a hit for is the non local one:
Quote:

An instance elsewhere in the cluster, if there is no local queue-manager instance. In this case only the following attributes can be inquired on. The QType attribute has the value MQQT_CLUSTER in this case.
DefBind
DefPersistence
DefPriority
InhibitPut
QDesc
QName
QType


Right you are, these should all be the same, so even further reason I think that the MQINQ call not always and everytime by default choosing the local instance is a design flaw.

If you hit the local instance, then you can MQINQ against useful things like qDepth and IPROCs and OPROCs that will be different between instances in the cluster. Yes, this is a little lightweight home grown monitoring app that works just great, except that I have to give it the authority to browse/put/get data or use the MQSET verb. I chose the lesser of 4 evils and gave it only +set figuring at least this way app data can't be messed with. But +set allows trigger settings to be messed with, or the queue to be inhibited. So now I have to deal with SSL or an Exit on a channel that really should only have the harmless +inq capability and nothing else.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
JosephGramig
PostPosted: Fri Oct 25, 2013 6:58 am Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1230
Location: Gold Coast of Florida, USA

Well, this link indicates if you specify the QmgrName in the MQOD on the MQOPEN, you will get the "one" you are looking for...
Back to top
View user's profile Send private message AIM Address
PeterPotkay
PostPosted: Fri Oct 25, 2013 12:02 pm Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

JosephGramig wrote:
Well, this link indicates if you specify the QmgrName in the MQOD on the MQOPEN, you will get the "one" you are looking for...



Initial testing with the API Excercisor that comes with MO71 shows that should do exactly what I want. If I set the QM name in the MQOD of the MQOPEN call it works with only MQOO_INQUIRE.

If I try again omitting the QM name in the MQOD I'm forced to specify anoter option.

Too easy! I'll change the code in my little app and see if it works there as well.

It breaks my rule of client apps not needing to know the QM name they are connecting to, but for a home grown monitoring app I can live with it. The monitoring app displays the name of the QM its showing data for anyway, so we have this info already.

Thanks Joseph!


If it works then I'll submit feedback on the Infocenter page I originally reference up above. It sent me down the wrong path not mentioning what Jospeh did.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Oct 25, 2013 12:51 pm Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Quote:
This question is all about the behavior of the MQINQ call and clustered queues

Don't know how reliable this information is going to be.
If the queue is not local to the qmgr you're connected to, you are being connected to a symbolic representation of what might look like a remote queue that may have been created by the qmgr on the fly to allow to route the message as requested.

I would want to either have the information on the SCTQ or the configured CTQ. What is wrong with requesting more info and targeting it then with pcf?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Fri Oct 25, 2013 1:32 pm Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

I only care about local instances of queues - this monitoring app connects directly to each QM and reports on q depth, IPROCS and OPROCS - that's it. Until now I thought I had to provide options on the MQOPEN other than MQOO_INQUIRE because the Info Center article I link to in my first post in this thread says I have, and the behavior confirms it.

But the link Joseph points to provides a somewhat obvious way to get around this - just specify the local QM name on the MQOPEN call if the queue you are interested in is on the local QM. If you do that it looks like MQOO_INQUIRE is all that's needed and I can drop the authority I give this User ID to just +connect and +inq.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Oct 25, 2013 7:11 pm Post subject: Reply with quote

Poobah

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

PeterPotkay wrote:
I only care about local instances of queues ...

I'm confused, as you posted this in the clusters forum. Are you inquiring on the CLUSTER attribute value (looking for null)?
_________________
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
View user's profile Send private message
PeterPotkay
PostPosted: Sat Oct 26, 2013 3:54 am Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

I only want to MQINQ against the local instance of a queue. That queue might be itself clustered and there might be other instances of that same queue name on other QMs in the cluster.

According to the InfoCenter link in my first post:
Quote:
Note: If you open a cluster queue without fixing the queue that MQOPEN has bound to, successive MQINQ calls might inquire on different instances of the cluster queue.


Further up on the same page:
Quote:
Combining MQOO_BROWSE, MQOO_INPUT_*, or MQOO_SET with MQOO_INQUIRE requires a local instance of the cluster queue for the open to succeed. In this case you can inquire on all the attributes that are valid for local queues.


This led me to believe the only way for me to MQINQ for things like Current Q Depth on a local queue that might have other instances of it in the cluster is to use MQOO_BROWSE, MQOO_INPUT_*, or MQOO_SET in addition to MQOO_INQUIRE. This required giving more access than I wanted to give - all I need is +inq.

Joseph's tip pointing to another page in the InfoCenter cleared the cobwebs. Specifying the local QM name in the MQOD on the MQOPEN call appears to fix the MQOPEN to the queue that I want (the local instance of the potentially clustered queue) and allows the MQINQ to grab things like Current Q Depth with only MQOO_INQUIRE needed on the MQOPEN. I'll be able to remove +set from this ID it seems. I'll need to test with the real app this coming week, but the MO71 API Exerciser confirms this line of thinking.

You typically don't specify the local QM name in the MQOD if you are opening the local queue on the QM you are connected to. In this case you might want to.
_________________
Peter Potkay
Keep Calm and MQ On
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 IndexClusteringMQINQ and Clusters and needing to give too much access
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.