| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| JMS App and Clustered Queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| ImSoTired |
 Posted: Mon May 26, 2008 8:19 am Post subject: JMS App and Clustered Queue |
 |
|
Novice
Joined: 17 Apr 2007
Posts: 20
Location: Lima, Perú
|
I have an issue with an MDB and WebSphere MQ  .
The application (MDB) runs on AIX v5.3 in a WebSphere Application Server v6.1 and access to MQ Objects using JMS, these objects are:
AIX v5.3
========
Queue Manager: QPIB1531 (CLUSTER - CLUSPLX5)
Queues:
- FE.APP.FEDSRV.REQ.01 (QLOCAL)
- OQ.APP.FEDSRV.RES.01 (QCLUSTER)
z/OS
====
Queue Manager: Q231 (CLUSTER - CLUSPLX5, Full Repository)
Queues:
- FE.APP.FEDSRV.REQ.01 (QCLUSTER)
- OQ.APP.FEDSRV.RES.01 (QLOCAL)
A program in Cobol runs in a z/OS System put messages on queue FE.APP.FEDSRV.REQ.01, these propagates over the Cluster Channels and activates the MDB on the AIX Box. The MDB processes the incoming messages and try to response to the replyToQueue and replyToQueueManager fields in the MQMD header with getJMSReplyTo like this:
qDestination = (Queue)msgInput.getJMSReplyTo();
queueName = qDestination.getQueueName();
The value for queueName is: queue://Q231/OQ.APP.FEDSRV.RES.01?targetClient=1
And it's here the problem. When the java process asociated to the AppServer where the MDB is deployed (that runs with an aix user call APFEDES that belong to the group GAPFEDES) try to put a message on queue OQ.APP.FEDSRV.RES.01 throws an:
javax.jms.JMSException: MQJMS2007: failed to send message to MQ queue.
LinkedException: com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2035.
I have to create an queue alias for security reasons:
DEFINE QALIAS(OQ.APP.FEDSRV.RES.01) TARGQ(OQ.APP.FEDSRV.RES.01)
The aix group have the following mq authorizations::
setmqaut -m QPIB1531 -t qmgr -g GAPFEDES +connect +inq
setmqaut -m QPIB1531 -n FE.APP.FEDSRV.REQ.01 -t q -g GAPFEDES +inq +get +browse
setmqaut -m QPIB1531 -n OQ.APP.FEDSRV.RES.01 -t q -g GAPFEDES +put
setmqaut -m QPIB1531 -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -t q -g GAPFEDES +put
and run the mqsc command REFRESH SECURITY.
but i have other problem:
javax.jms.JMSException: MQJMS2007: failed to send message to MQ queue.
LinkedException: com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2001.
This indicates that the type of base queue name is invalid. Well, i try this operation again but this time i deleted the alias definition, and i get the following exception:
javax.jms.JMSException: MQJMS2007: failed to send message to MQ queue.
LinkedException: com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2085.
Is there anything that i forgot it?, to fix temporaly i create a sender-reciever channel between the queue managers and i grant a 'put' access to the transmission queue 'Q231' placed in the aix, but there's no remote queue definitions that use this transmition queue, and the messages placed in this transmission queue are propagated through the sender-reciever channel to the z/OS system.
Please your help!
Thanks for your time |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon May 26, 2008 8:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Wrong assumption. Do not create an Alias.
Just authorize running setmqaut the target queue (even though it doesn't exist) on the AIX (putting) qmgr. You can use a generic pattern.
The cluster queue at runtime is then treated locally as a remote queue and the pattern is authorized.
You may also have to authorize the cluster xmitq or create an authorized qmgr alias for the destination qmgr.
IIRC you can only use the local authorization pattern if the reply to qmgr is blank as you are sending the reply. The other possibility is to create a qmgr alias on the replyto qmgr and cluster it. Give put authorization to the qmgr alias on the sending qmgr (server).
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ImSoTired |
| Posted: Wed May 28, 2008 10:10 am Post subject: |
|
|
Novice
Joined: 17 Apr 2007
Posts: 20
Location: Lima, Perú
|
Thanks for your help fjb_saper, i just grant a put access to the group GAPFEDES over the SYSTEM.CLUSTER.TRANSMIT.QUEUE and it's works fine! 
But i have a question about this: when i used another MDB that uses the MQI API to put messages to the queue, why it's not necessary grant a put access to the cluster xmit queue?  because i do another test with MQI and just grant access to the local queues that the application uses and there was no problems of security. It's an issue only with JMS?
Thanks!! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 28, 2008 3:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ImSoTired wrote: |
Thanks for your help fjb_saper, i just grant a put access to the group GAPFEDES over the SYSTEM.CLUSTER.TRANSMIT.QUEUE and it's works fine!
But i have a question about this: when i used another MDB that uses the MQI API to put messages to the queue, why it's not necessary grant a put access to the cluster xmit queue? because i do another test with MQI and just grant access to the local queues that the application uses and there was no problems of security. It's an issue only with JMS?
Thanks!! |
You really should avoid granting put to SYSTEM.CLUSTER.TRANSMIT.QUEUE. Now that group has access to all queue managers in the cluster! Remember that JMS needs inq on top of whatever authorization you have in mind... Giving authority to a qmgr ALIAS would have done the trick and limited the access to that additional qmgr...
Enjoy
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
