| Author |
Message
|
| vsathyan |
 Posted: Mon Dec 29, 2014 1:06 am Post subject: MQRC 2082 - Alias to Local (Cluster Queue in different qmgr) |
 |
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
There are two queue managers - QM1, QM2. Both are partial repositories
of cluster - CLUS.
QM1
-------------------------------------------
DEFINE QA(ALIASQ) TARGET(BASEQ)
-------------------------------------------
The above alias queue is not shared in cluster, but its base queue is a local queue, which is shared in cluster - CLUS.
QM2
-------------------------------------------
DEFINE QL(BASEQ) CLUSTER(CLUS) DEFBIND(NOTFIXED) CLWLUSEQ(ANY)
-------------------------------------------
When i run - DISPLAY QC(BASEQ) on QM1, it is able to resolve the cluster queue in QM2.
The application is hosted on WebLogic, and hope the weblogic MQ adapter is opening the alias queue with both - MQOO_OUTPUT and MQOO_INPUT_AS_Q_DEF. Due to this, since the alias base queue is not present in QM1, it is throwing MQRC 2082, as it cannot resolve the base queue. However, the queue manager QM1 is able to view the cluster queue.
Tried with sample applications, and only a MQOO_OUTPUT (open the queue for put) works fine.
But if i try to open the queue with MQOO_INPUT_AS_Q_DEF (open the queue for get), it fails because the alias queue cannot get messages from a queue present on a different queue manager. I know cluster queues are put anywhere, get local.
I dont have control over the weblogic adapter code to make sure it opens only the queue with MQOO_OUTPUT option.
Currently, there is only one instance of cluster queue - BASEQ (in QM2). I can add one more instance of the same cluster queue - BASEQ in QM1, make the maxdepth(0), and increase the priority of the queue in QM2 so that messages always get delivered to the BASEQ in QM2.
I tried the above option, and it works. The application will not face 2082 in above approach.
What other options can be used other than using point to point (remote-local) queue setup and the option i specified above to avoid getting 2082?
Thanks in advance. |
|
| Back to top |
|
 |
| vsathyan |
| Posted: Mon Dec 29, 2014 5:22 am Post subject: |
|
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
Update : The message flow is like below
Source Application -> Alias Q (QM1) -> Cluster Local Q (QM2) -> Alias Q (QM2) -> Destination Application |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Dec 29, 2014 7:39 am Post subject: Re: MQRC 2082 - Alias to Local (Cluster Queue in different q |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| vsathyan wrote: |
Currently, there is only one instance of cluster queue - BASEQ (in QM2). I can add one more instance of the same cluster queue - BASEQ in QM1, make the maxdepth(0), and increase the priority of the queue in QM2 so that messages always get delivered to the BASEQ in QM2.
I tried the above option, and it works. The application will not face 2082 in above approach.
|
Did that actually work? That's kind of clever!
| vsathyan wrote: |
What other options can be used other than using point to point (remote-local) queue setup and the option i specified above to avoid getting 2082?
|
That won't work if the putting app insists on opening the queue for input. You can't open a remote q def for input.
Fix the app. Its one line of code to remove an inappropriate option being used on the MQOPEN.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| vsathyan |
| Posted: Mon Dec 29, 2014 7:52 am Post subject: |
|
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
| Quote: |
Did that actually work? That's kind of clever!
|
Yes, it worked!
| Quote: |
That won't work if the putting app insists on opening the queue for input. You can't open a remote q def for input.
|
Yep, right.
Though it is a one line code change of removing MQC.MQOO_INPUT* open option, we dont have the control, as it is not a custom written code / application, and probably a weblogic mq adapter which is making the connections to MQ and opening the queue.
I have to catch a weblogic admin and find out if there are some parameters which can be set while connecting to MQ and opening queues. If yes, remove the input open option and try again.
Thanks |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 29, 2014 1:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| vsathyan wrote: |
| Quote: |
Did that actually work? That's kind of clever!
|
Yes, it worked!
| Quote: |
That won't work if the putting app insists on opening the queue for input. You can't open a remote q def for input.
|
Yep, right.
Though it is a one line code change of removing MQC.MQOO_INPUT* open option, we dont have the control, as it is not a custom written code / application, and probably a weblogic mq adapter which is making the connections to MQ and opening the queue.
I have to catch a weblogic admin and find out if there are some parameters which can be set while connecting to MQ and opening queues. If yes, remove the input open option and try again.
Thanks |
Well seeing that this is weblogic, make sure the application is never trying to receive from the queue... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| vsathyan |
| Posted: Mon Dec 29, 2014 10:35 pm Post subject: |
|
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
| fjb_saper wrote: |
Well seeing that this is weblogic, make sure the application is never trying to receive from the queue... |
Yes, it is. I wrote a small app shared in the below link to test the open option. And yes, when I checked the MQOO_INPUT* options to open the queue, I got MQRC 2082.
So, definitely the app is opening the queue with read open option.
https://drive.google.com/file/d/0BwlHDaZdXLIUTmRXcHdJZ0YwVmM/view?usp=sharing |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 30, 2014 3:52 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| vsathyan wrote: |
| fjb_saper wrote: |
Well seeing that this is weblogic, make sure the application is never trying to receive from the queue... |
Yes, it is. I wrote a small app shared in the below link to test the open option. And yes, when I checked the MQOO_INPUT* options to open the queue, I got MQRC 2082.
So, definitely the app is opening the queue with read open option.
https://drive.google.com/file/d/0BwlHDaZdXLIUTmRXcHdJZ0YwVmM/view?usp=sharing |
Here comes the crux: your program is written in .NET...
This being WebLogic I expected something in JMS...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| vsathyan |
| Posted: Tue Dec 30, 2014 8:07 am Post subject: |
|
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
| fjb_saper wrote: |
Here comes the crux: your program is written in .NET...
This being WebLogic I expected something in JMS... |
We have testing using a Java code too. Same exception. 
And I believe it doesn't matter what app is connecting from any platform, when the right open options are used while opening the queue. My thoughts though! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Dec 30, 2014 8:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You are correct that you can't get from anything that's not a qlocal.
You need to work on the weblogic JMS config to ensure that the application doesn't try to create a consumer against a queue that is not local. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 30, 2014 12:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| vsathyan wrote: |
And I believe it doesn't matter what app is connecting from any platform, when the right open options are used while opening the queue. My thoughts though! |
Agree entirely. Now you have to figure out how JMS sets the open options... and mqjeff gave you the same pointer I did earlier... so take heed...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
