| Author |
Message
|
| PeterPotkay |
 Posted: Thu Oct 24, 2013 7:22 am Post subject: MQINQ and Clusters and needing to give too much access |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
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 |
|
 |
| bruce2359 |
| Posted: Thu Oct 24, 2013 8:38 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Oct 24, 2013 8:57 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
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 |
|
|
| bruce2359 |
| Posted: Thu Oct 24, 2013 9:16 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| PeterPotkay |
| Posted: Thu Oct 24, 2013 9:23 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
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 |
|
|
| gbaddeley |
| Posted: Thu Oct 24, 2013 3:04 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
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 |
|
|
| bruce2359 |
| Posted: Thu Oct 24, 2013 6:09 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| PeterPotkay |
| Posted: Fri Oct 25, 2013 5:09 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| 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 |
|
|
| JosephGramig |
| Posted: Fri Oct 25, 2013 6:58 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
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 |
|
|
| PeterPotkay |
| Posted: Fri Oct 25, 2013 12:02 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| 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 |
|
|
| fjb_saper |
| Posted: Fri Oct 25, 2013 12:51 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
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 |
|
|
| PeterPotkay |
| Posted: Fri Oct 25, 2013 1:32 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
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 |
|
|
| bruce2359 |
| Posted: Fri Oct 25, 2013 7:11 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| PeterPotkay |
| Posted: Sat Oct 26, 2013 3:54 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
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 |
|
|
|
|
