| Author |
Message
|
| Jeff.VT |
 Posted: Fri Oct 05, 2018 11:41 am Post subject: Cluster to Cluster Alias |
 |
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
Queue Manager: SOURCE
QM Cluster: ONE
Has an alias queue (ONE.TO.TWO) going to "ONE.TO.TWO.CLUSTERED"
Queue Manager: MIDDLEMAN
QM Cluster: ONE
QM Cluster: TWO
ONE.TO.TWO.CLUSTERED is an alias queue on the ONE Cluster that points to "TWO.QUEUE" (a queue on the TWO Cluster)
Queue Manager: ENDPOINT
QM Cluster: TWO
Clustered Queue: TWO.QUEUE
-------------
Why doesn't this work?
When I put a message on "ONE.TO.TWO.CLUSTERED" on MIDDLEMAN directly, it sends it to TWO.QUEUE just fine.
But when I put a message on ONE.TO.TWO on SOURCE, it gets an Alias error... whycome?
 [/img] |
|
| Back to top |
|
 |
| Jeff.VT |
| Posted: Fri Oct 05, 2018 12:01 pm Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
ROFL... Okay... what a weird way to fix this.
I can't understand why this works AT ALL, but it does >_<
I have some other cluster queues and we sort of use this empty remote queue as some kind of a target point to get us to the other cluster. But we've only directly pointed there. If I add it to the "TWO" cluster, everything breaks. But I wondered... what if I put that queue in the "ONE" cluster?
It works... I have zero clue why, but it works >_<
Queue Manager: SOURCE
Remote Queue Name: ONE.TO.TWO
Remote Queue : TO.TWO
Remote Queue Manager: MIDDLEMAN.BOUNCE
XMIT Q: <blank>
Queue Manager: MIDDLEMAN
Remote Queue Name: MIDDLEMAN.BOUNCE
Remote Queue Manager: <blank>
Remote Queue: <blank>
XMIT Q: <blank>
Added to cluster: ONE
------------
WHY on EARTH did that work?!?!
Though I'd say I'd prefer it if the target queue was on MIDDLEMAN - I can live with it being on SOURCE. |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Oct 05, 2018 12:36 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
If could be that one of your alias queue definitions has an attribute of DEFBIND(OPEN). If so, changing it to DEFBIND(NOTFIXED) may fix the issue.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| Jeff.VT |
| Posted: Fri Oct 05, 2018 1:46 pm Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
That didn't work.
I think it's some weird interaction between the two clusters.
I'd wonder if I added that alias queue to both clusters if it would work - but I don't control the TWO cluster enough to play with it. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 05, 2018 2:52 pm Post subject: Re: Cluster to Cluster Alias |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Jeff.VT wrote: |
Queue Manager: SOURCE
QM Cluster: ONE
Has an alias queue (ONE.TO.TWO) going to "ONE.TO.TWO.CLUSTERED"
Queue Manager: MIDDLEMAN
QM Cluster: ONE
QM Cluster: TWO
ONE.TO.TWO.CLUSTERED is an alias queue on the ONE Cluster that points to "TWO.QUEUE" (a queue on the TWO Cluster)
Queue Manager: ENDPOINT
QM Cluster: TWO
Clustered Queue: TWO.QUEUE
-------------
Why doesn't this work?
When I put a message on "ONE.TO.TWO.CLUSTERED" on MIDDLEMAN directly, it sends it to TWO.QUEUE just fine.
But when I put a message on ONE.TO.TWO on SOURCE, it gets an Alias error... whycome?
|
I agree, this should work.
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.ref.adm.doc/q085700_.html
| Quote: |
| If the alias refers to a queue, it must be another local or remote queue, defined at this queue manager, or a clustered alias queue defined on another queue manager. |
Using this for some ideas:
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.tro.doc/q041470_.html
| Quote: |
This reason code can also occur when BaseQName is the name of a cluster queue that cannot be resolved successfully. |
Connect to Queue Manager "SOURCE" and do an MQOPEN of queue name "ONE.TO.TWO.CLUSTERED ". Does that work?
If no, work the problem here. You have a (relatively) basic MQ Name resolution problem to solve and have gotten one step closer to the actual failure point.
If it does work, see next point:
| Quote: |
MQRC_UNKNOWN_ALIAS_BASE_Q might indicate that the application is specifying the ObjectQmgrName of the queue manager that it is connecting to, and the queue manager that is hosting the alias queue. This means that the queue manager looks for the alias target queue on the specified queue manager and fails because the alias target queue is not on the local queue manager. Leave the ObjectQmgrName parameter blank so that the clustering decides which queue manager to route to. |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 05, 2018 3:15 pm Post subject: Re: Cluster to Cluster Alias |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Jeff.VT wrote: |
Why doesn't this work?
When I put a message on "ONE.TO.TWO.CLUSTERED" on MIDDLEMAN directly, it sends it to TWO.QUEUE just fine.
But when I put a message on ONE.TO.TWO on SOURCE, it gets an Alias error... whycome?
|
Exactly and precisely how did you put a message?
Did you use the IBM-supplied utility amqsput or amqsputc? If so, re-run the commands (the one that worked and the one that resulted in the error), and post the command and results here.
_________________
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 |
|
|
| tczielke |
| Posted: Fri Oct 05, 2018 5:51 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| Jeff.VT wrote: |
That didn't work.
I think it's some weird interaction between the two clusters.
I'd wonder if I added that alias queue to both clusters if it would work - but I don't control the TWO cluster enough to play with it. |
To confirm, did you check the DEFBIND on the ONE.TO.TWO qalias queue definition?
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| Jeff.VT |
| Posted: Mon Oct 08, 2018 8:43 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
The way I checked it was with a MS0P MQ Explorer tools trace of the alias queue on SOURCE.
So I wouldn't think binding should matter there.
Doing the same trace on the MIDDLEMAN queue works fine. |
|
| Back to top |
|
|
| Jeff.VT |
| Posted: Mon Oct 08, 2018 9:07 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
| tczielke wrote: |
| Jeff.VT wrote: |
That didn't work.
I think it's some weird interaction between the two clusters.
I'd wonder if I added that alias queue to both clusters if it would work - but I don't control the TWO cluster enough to play with it. |
To confirm, did you check the DEFBIND on the ONE.TO.TWO qalias queue definition? |
I tried NOTFIXED, ON Open, and On Group (ON group is what i'd want) on both. No combination of default bind types seemed to make a difference. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 08, 2018 9:25 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Jeff.VT wrote: |
| The way I checked it was with a MS0P MQ Explorer tools trace of the alias queue on SOURCE. |
Sorry if I wasn't clear in my question. I asked how you tested, not what tool did you use to test.
Did your test explicitly specify the queue name AND qmgr name where the message should go? Or did you let clustering software decide to which qmgr the message should go?
_________________
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 |
|
|
| Jeff.VT |
| Posted: Mon Oct 08, 2018 9:39 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
| bruce2359 wrote: |
| Jeff.VT wrote: |
| The way I checked it was with a MS0P MQ Explorer tools trace of the alias queue on SOURCE. |
Sorry if I wasn't clear in my question. I asked how you tested, not what tool did you use to test.
Did your test explicitly specify the queue name AND qmgr name where the message should go? Or did you let clustering software decide to which qmgr the message should go? |
Ooooooooooh Good question... Interesting. So I tried to set up a remote queue on SOURCE that points to the alias queue on MIDDLEMAN, and I got that same error... Even when I removed that alias queue on MIDDLEMAN from the cluster.
So it's not a cluster>cluster issue as much as I thought it was. |
|
| Back to top |
|
|
| Jeff.VT |
| Posted: Mon Oct 08, 2018 9:49 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
So If I have a remote queue on SOURCE that uses the weird Cluster pass-through empty remote queue trick thing on the MIDDLEMAN queue manager, then it works.
But I can't get to it any other way. So that makes sense, I guess...
The work-around way I got it to work, by making an empty remote queue on MIDDLEMAN and sharing that to the cluster, then using that as the Queue Manager name, with a blank xmit queue name on SOURCE, that'll get there.
It sucks, but it's not unexpected.
----------
As a quick FYI - I can't control how my apps put messages to queues. They basically always do it a similar way. So I can't have them specify that blank remote queue in for the queue manager trick. It has to be straightforward.
I've never seen an instance where a queue traces correctly or incorrectly but my applications work differently. So I'd presume they use a similar method. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 08, 2018 11:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Jeff.VT wrote: |
| Ooooooooooh Good question... |
We try.
| Jeff.VT wrote: |
| Interesting. So I tried to set up a remote queue on SOURCE that points to the alias queue on MIDDLEMAN, and I got that same error... Even when I removed that alias queue on MIDDLEMAN from the cluster. |
Please use mq script command to display the complete qremote def your test app MQOPENS. Post the results here.
| Jeff.VT wrote: |
| So it's not a cluster>cluster issue as much as I thought it was. |
Too soon to tell.
Ask your developers if they explicitly specify the qmgrname in the MQOD (object descriptor) for the MQOPEN call.
_________________
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 |
|
|
| gbaddeley |
| Posted: Mon Oct 08, 2018 3:25 pm Post subject: Re: Cluster to Cluster Alias |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Jeff.VT wrote: |
Queue Manager: SOURCE
QM Cluster: ONE
Has an alias queue (ONE.TO.TWO) going to "ONE.TO.TWO.CLUSTERED"
Queue Manager: MIDDLEMAN
QM Cluster: ONE
QM Cluster: TWO
ONE.TO.TWO.CLUSTERED is an alias queue on the ONE Cluster that points to "TWO.QUEUE" (a queue on the TWO Cluster)
Queue Manager: ENDPOINT
QM Cluster: TWO
Clustered Queue: TWO.QUEUE
-------------
Why doesn't this work?
When I put a message on "ONE.TO.TWO.CLUSTERED" on MIDDLEMAN directly, it sends it to TWO.QUEUE just fine.
But when I put a message on ONE.TO.TWO on SOURCE, it gets an Alias error... whycome?
|
This is a standard technique to provide "cluster cross-over". It should work. We use it often.
qalias "ONE.TO.TWO" should just have a target queue name of "ONE.TO.TWO.CLUSTERED", with no target qmgr or cluster settings. Queue Manager SOURCE will resolve the target name, and find that "ONE.TO.TWO.CLUSTERED" it a clustered object in ONE cluster on MIDDLMAN.
The message will be transported to MIDDLEMAN, which will then resolve the target of qalias "ONE.TO.TWO.CLUSTERED".
_________________
Glenn |
|
| Back to top |
|
|
| tczielke |
| Posted: Mon Oct 08, 2018 4:29 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
The Application Activity Trace would be helpful here to see what is happening. It shows the name resolution that is happening with the MQOPEN calls, and I am pretty sure it should show you the name resolution that is causing the 2082 error.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
|
|
