| Author |
Message
|
| vc1981 |
 Posted: Thu Feb 22, 2007 4:24 am Post subject: 2082 on an Cluster Alias queue ; but amqsput works |
 |
|
Apprentice
Joined: 18 Jan 2006
Posts: 46
|
Hi,
Ref : http://www.mqseries.net/phpBB2/viewtopic.php?p=168787#168787
I have two queue managare QM1 and QM2 in a cluster CLUS
The Queue Manager QM1 has an alias queue A1 not shared in the cluster CLUS , the target queue for this is a local queue L1 defined under QM2 and shared in CLUS .
Now when i try to put the message on A1 using my Java client i get an error message:
MQJE001: Completion Code 2, Reason 2082
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2082
at com.ibm.mq.MQQueueManager.accessQueue(MQQueueManager.java:1544)
But when i use amqsput A1 QM1 then it works fine .
Also from QM1 when i do an Dis Qcluster(L1) i can see the queue .
TO summarise:
There are two queue managers both are member of the cluster called CLUS.
Queue Manager : QM1
Alias queue : A1 ( not shared in the cluster) Target Q is L1
Queue Manager : QM2
Local queue : L1 shared in the cluster called CLUS
when the target queue for the alias queue is an queue local to the queue manager , then the same code works, but then that won't serve the purpose i need to make use of clustering , as going forward i would be implementing load balancing as well.
Also this queue manager QM1 of mine is the default queue manager of mine , so when i run the code without mentioning any queue manager name , the application works fine , that to a great extent indicates that when we mention a queue manager name , the application probably looks for the target queue under the same queue manager !
Wonder how this can be done away , as i won't be using the default queue manager always.
_________________
Regards ,
VC |
|
| Back to top |
|
 |
| dsriksha |
| Posted: Fri Feb 23, 2007 11:19 am Post subject: |
|
|
Voyager
Joined: 27 Feb 2005
Posts: 95
|
| If L1 is a cluster queue, I believe u can directly access the queue L1 connecting to the QM1. |
|
| Back to top |
|
|
| vc1981 |
| Posted: Sun Feb 25, 2007 8:24 pm Post subject: |
|
|
Apprentice
Joined: 18 Jan 2006
Posts: 46
|
L1 is the cluster queue defined under QM2 so how can i access it form my applicaiton by connecting to QM1 ?
_________________
Regards ,
VC |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Feb 25, 2007 8:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| vc1981 wrote: |
| L1 is the cluster queue defined under QM2 so how can i access it form my applicaiton by connecting to QM1 ? |
Depending on the form of java used you may have to define a "cluster" alias.
This is done like this and assumes the qmgr is part of the cluster:
| Code: |
| def qr(myclusteralias) |
Particularly in JMS you would then define the cluster queue like this:
| Code: |
| Session.createQueue("queue://MYCLUSTERALIAS/L1?targetClient=1"); |
This should then allow you to put to the cluster queue from QM1 in java / JMS
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Feb 26, 2007 2:47 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It shouldn't be necessary to use a qremote or a local qalias to put to a qcluster from JMS.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 27, 2007 10:39 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
| It shouldn't be necessary to use a qremote or a local qalias to put to a qcluster from JMS. |
Agreed. But this requires that you are very careful setting up your JNDI layer.
I have seen cases where it is just easier to use a cluster alias than to go straight to a cluster queue.
(Imagine pub/sub subscriptions...)
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Feb 27, 2007 11:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| fjb_saper wrote: |
| Agreed. But this requires that you are very careful setting up your JNDI layer. |
Which is, in fact, what vc1981 is asking for help with... 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 27, 2007 12:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
Also this queue manager QM1 of mine is the default queue manager of mine , so when i run the code without mentioning any queue manager name , the application works fine , that to a great extent indicates that when we mention a queue manager name , the application probably looks for the target queue under the same queue manager !
Wonder how this can be done away , as i won't be using the default queue manager always. |
Not quite true. JMS will use cluster resolution if the JNDI information for the qmgr on the queue is blank (spaces) or (queue:///qname). However the default is that it will first try to identify the qname on the qmgr the connection points to.
This has very little to do with a default qmgr but may seem to behave so.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| vc1981 |
| Posted: Thu Mar 15, 2007 9:20 pm Post subject: |
|
|
Apprentice
Joined: 18 Jan 2006
Posts: 46
|
I am sorry , though i know MQ a bit , but i am not a Java kiddoo ....
so what u guys suggest me to do to resolve the above error of 2082.
My code looks something like this !
mqqueuemanager = new MQQueueManager(qmanagername);
int openOptions = MQC.MQOO_OUTPUT;
queue = mqqueuemanager.accessQueue(qname,
openOptions,
qmanagername,
null, // no dynamic q name
null); // no alternate user id
MQMessage objMQMessage = new MQMessage();
objMQMessage.writeString(message);
MQPutMessageOptions pmo = new MQPutMessageOptions();
queue.put(objMQMessage, pmo);
_________________
Regards ,
VC |
|
| Back to top |
|
|
| jsware |
| Posted: Fri Mar 16, 2007 12:41 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| vc1981 wrote: |
queue = mqqueuemanager.accessQueue(qname,
openOptions,
qmanagername,
null, // no dynamic q name
null); // no alternate user id |
I think you should not specify the qmanagename in this call otherwise you are bypassing queue name resolution and asking for queue {qname} on qmgr {qmanagername} Its like providing the qmgr name in the MQOPEN's MQOD object descriptor argument, you only typically need to do this if you are replying to a message and have the queue/qmgr reply-to details in your received MQMD. I think you can use null for the qmanagername argument too.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| vc1981 |
| Posted: Fri Mar 16, 2007 1:52 am Post subject: |
|
|
Apprentice
Joined: 18 Jan 2006
Posts: 46
|
Thanks a lot scottj2512.i removed the qmanagername wil opening the queue and it works now !
_________________
Regards ,
VC |
|
| Back to top |
|
|
|
|
