| Author |
Message
|
| mqperson |
 Posted: Mon Aug 13, 2007 11:17 am Post subject: Cluster Queues and Client applications |
 |
|
Apprentice
Joined: 10 Jan 2006
Posts: 32
|
I have learnt two cluster related things in the last week and am looking for some kind of ratification here..
1) We have 2 qmgrs in a cluster - qm1 and qm2. qm1 is the gateway that has the remote queue definitions (that are shared in the cluster) and the channels to the outside world. qm2 has the local queues shared in the cluster.
We have client applications connect to qm2 and put/get messages to the local and remote queues. I see that when the client application has to put a message to the remote queue (defined on qm1 and shared in cluster), the application returns a 2035. I defined a qalias on qm2 to point to the remote cluster queue on qm1. I have also shared this qalias in the cluster. Now the client application is able to put to the remote queue without any problems.
Is this how remote queues in a cluster are designed to work with client apps ?
2) Earlier, I had the application guys change their open call to include MQOO_SET and MQOO_INQUIRE when they inquire local queues. I am sure they did not like it, but since we were moving to a new cluster setup, I had to have them do it. But I do not understand why MQ wants it that way for local cluster queues. Any light on this will better my understanding.
Thanks in advance. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Aug 13, 2007 11:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
2035 is a security violation. There shouldn't be a difference between remote & alias queues per se. Check the security settings for the 2 queues.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqperson |
| Posted: Mon Aug 13, 2007 12:51 pm Post subject: |
|
|
Apprentice
Joined: 10 Jan 2006
Posts: 32
|
I am sorry, I forgot to mention that qm1 and qm2 are on two different servers. Both unix servers have a user "tmpusr". tmpusr has "all" access on the local and remote cluster queues. The clients connect on a svrconn that has mcauser as "tmpusr".
All I did was define the qalias to get rid of the 2035. I thought MQ was not able to resolve access to the remote queue on qm1 from qm2 even though it is part of the cluster. Is it because its on a physically different server ? The clients connect to qm2. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 13, 2007 12:55 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
When you defined the qalias, you defined it as an object that the client user had permissions for, in some way or another.
Without the qalias, the OAM is going to try and authorize the user against SYSTEM.CLUSTER.TRANSMIT.QUEUE directly.
You never want to give the user permissions to that queue, and it's not done by default.
So the QALIAS resolved your 2035 by changing what object the OAM was authorizing against.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mqperson |
| Posted: Mon Aug 13, 2007 1:04 pm Post subject: |
|
|
Apprentice
Joined: 10 Jan 2006
Posts: 32
|
Thanks Jeff. I still have 2 questions -
1) I tried setting mqauths on the S.C.T.Q. That did not help. I backed out the changes though. Was it supposed to work ?
2) Is this behavior because the connecting application is a client ? External systems that connect to qm1 as a server are able to access cluster queues on qm2 without any issues.
Thanks in advance.. |
|
| Back to top |
|
|
|
|
