| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Alias queue to a cluster queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Fri Aug 24, 2012 6:49 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Vitor wrote: |
| Boomn4x4 wrote: |
| So, if I'm understanding all of this correctly, there is 0 value in having a cluster in this scenario? In that QALIAS's don't work in clusters? |
If all you're trying to do is hop the message from A->B->C then no, I doubt a cluster adds much to that scenario. The prevaling assumption is that A is outside the cluster, B is the gateway to the cluster and C is the internal target. Otherwise your topology doesn't make apparent sense.
Clusters are intended for other things, hence they don't add to a multi-hop point to point scenario. |
WMQ channels are point-to-point. One advantage of clusters is that multiple hops are not necessary - cluster channels will be used to move messages between cluster qmgrs.
If your sole purpose is to multi-hop, this can be done without clusters. If you have clusters, you can still multi-hop, but why would you want to?
Please read about WMQ clusters in the WMQ InfoCenter (or the equivalent manuals).
_________________
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 |
|
 |
| mqjeff |
| Posted: Fri Aug 24, 2012 6:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| Vitor wrote: |
| Boomn4x4 wrote: |
| So, if I'm understanding all of this correctly, there is 0 value in having a cluster in this scenario? In that QALIAS's don't work in clusters? |
If all you're trying to do is hop the message from A->B->C then no, I doubt a cluster adds much to that scenario. The prevaling assumption is that A is outside the cluster, B is the gateway to the cluster and C is the internal target. Otherwise your topology doesn't make apparent sense.
Clusters are intended for other things, hence they don't add to a multi-hop point to point scenario. |
WMQ channels are point-to-point. One advantage of clusters is that multiple hops are not necessary - cluster channels will be used to move messages between cluster qmgrs.
If your sole purpose is to multi-hop, this can be done without clusters. If you have clusters, you can still multi-hop, but why would you want to?
Please read about WMQ clusters in the WMQ InfoCenter (or the equivalent manuals). |
Bruce, Vitor.
This is *basic* Cluster Gateway setup.
This is a perfectly fine idea and should be pursued in any case where you have a queue manager that is NOT in the cluster that needs to speak to a queue manager that IS in the cluster.
There's plenty of good reason for configuring objects to perform multi-hopping in that scenario, because you need to dedicate a SINGLE point where the non-clustered queue manager connects to the cluster. And all objects MUST then multi-hop INTO the cluster from there.
Bruce, with deepest respect, you've spent a lot of time posting generic stuff into this thread and hiding the specific facts I've provided behind them. |
|
| Back to top |
|
|
| Boomn4x4 |
| Posted: Fri Aug 24, 2012 7:17 am Post subject: |
|
|
Disciple
Joined: 28 Nov 2011
Posts: 172
|
| mqjeff wrote: |
| bruce2359 wrote: |
| Vitor wrote: |
| Boomn4x4 wrote: |
| So, if I'm understanding all of this correctly, there is 0 value in having a cluster in this scenario? In that QALIAS's don't work in clusters? |
If all you're trying to do is hop the message from A->B->C then no, I doubt a cluster adds much to that scenario. The prevaling assumption is that A is outside the cluster, B is the gateway to the cluster and C is the internal target. Otherwise your topology doesn't make apparent sense.
Clusters are intended for other things, hence they don't add to a multi-hop point to point scenario. |
WMQ channels are point-to-point. One advantage of clusters is that multiple hops are not necessary - cluster channels will be used to move messages between cluster qmgrs.
If your sole purpose is to multi-hop, this can be done without clusters. If you have clusters, you can still multi-hop, but why would you want to?
Please read about WMQ clusters in the WMQ InfoCenter (or the equivalent manuals). |
Bruce, Vitor.
This is *basic* Cluster Gateway setup.
This is a perfectly fine idea and should be pursued in any case where you have a queue manager that is NOT in the cluster that needs to speak to a queue manager that IS in the cluster.
There's plenty of good reason for configuring objects to perform multi-hopping in that scenario, because you need to dedicate a SINGLE point where the non-clustered queue manager connects to the cluster. And all objects MUST then multi-hop INTO the cluster from there.
Bruce, with deepest respect, you've spent a lot of time posting generic stuff into this thread and hiding the specific facts I've provided behind them. |
We have several thousand cleint qmgrs that need to post messages to a host qmgr. When the origninal architecture was determine, the 'easiest' approach was to put them all in a cluster. When IBM was brought it to review what we had, they scoffed at the number of qmgrs in the cluster, they didn't feel comfortable with more than 1,000.
The second approach were to have 1,000 clients in client clusters, with a single gateway. The gateway was a member of the client clusters and the host cluster. In thinking this trough, since we were already out of the 'easiest' scenario and that there was no need for intercommunication between the client systems, the client clusters didn't seem to have any value. From there, it was determined to use remote queue to send to the gateway, which would have an alias to hop to the host. Herein lied my problem.
| mqjeff wrote: |
As I said, IF YOU WANT to use a QALIAS, |
I do....
| mqjeff wrote: |
| it must be on the same queue manager that it points to. |
...but I can't
| mqjeff wrote: |
| As I said, IF the QALIAS is defined on QMGRB, it should not be. |
.. It was
| mqjeff wrote: |
| It should be defined on QMGRC and the QLOCAL should *not* be shared in the cluster. |
This doesn't provide load balancing... no dice
| mqjeff wrote: |
| As I said, IF YOU WANT to define an object on QmgrB, it MUST be a Qremote. |
... and here, I believe, is my answer.
If I want to multi hop INTO a cluster, it must be done via QREMOTE.
I think, its all coming together. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 24, 2012 7:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Boomn4x4 wrote: |
| If I want to multi hop INTO a cluster, it must be done via QREMOTE. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 24, 2012 7:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Okay, so again.
You're still missing the boat.
There are several ways to slice this bread.
You can EITHER use a single qremote on the gateway, or you can share a qalias in the cluster INSTEAD of the qlocal, for each copy of the qlocal there is.
So if you have several copies of the qlocal, one on QmgrC, D, E, F, etc... you can create a qalias on C,D,E,F,etc. and share those in the cluster.
I have also chosen to ignore Vitor's basic suggestion of using a cluster alias. This is a qremote on QmgrB that will clear out the queue manager name portion of the address - that will NOT get touched by the QALIAS you defined on QmgrB. That's another choice.
As Bruce has said, this is all MQ name resolution, and you need to think of it like that, focusing on the queue and queue manager names that are being resolved at each place. |
|
| Back to top |
|
|
| Boomn4x4 |
| Posted: Fri Aug 24, 2012 8:35 am Post subject: |
|
|
Disciple
Joined: 28 Nov 2011
Posts: 172
|
| mqjeff wrote: |
Okay, so again.
You're still missing the boat. |
Thanks for being patient with me on this one... I THINK I may have a dim light bulb.
I've got the QREMOTE scenario working just fine.
I'm still playing around with the QALIAS with clusters and keep getting MQRC_ALIAS_BASE_Q_TYPE_ERROR
I'm looking through the documentation for name resolution:
Local queue manager - Alias queue with CLUSTER attribute - The alias must not resolve to a cluster queue that is not locally defined, or a cluster queue that has the same ObjectName as the alias.
Blank queue manager - Alias queue with CLUSTER attribute - The alias can resolve to a cluster queue with same ObjectName as the alias.
It looks like the messages I am putting on the queue, via amqsput and the "put test message" with the MQ Explorer. I believe BOTH put the MOD Qmgr name as the local queue. This is leading me to beleive that in doing so, I am following the resolution rule as I have in bold above.
In order for me to get this to work, I have to put the message on the queue with a blank name? Am I getting close? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Aug 24, 2012 9:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
No. Alias-to-base-queue error means that the QAlias def has a TARGET attribute you specified is NOT valid. A qa target must be a ql or qr.
Post your qa def 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.
Last edited by bruce2359 on Fri Aug 24, 2012 10:27 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 24, 2012 9:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Okay. So, again. Look at the message on the DLQ. Look at the fields in the DLQHeader that tell you what the message destination was.
That tells you what the address that was *attempted* to be resolved was. That will allow you to troubleshoot almost all MQ name resolution issues - once you back track the message through it's path to figure out how it came to have those values in the first place.
The naming rule you put in bold is what I've already said - a qalias *must* point to an object defined on the *same* queue manager. A qcluster is not *defined* on the local qmgr, it's merely *known* to the local qmgr.
You can't use a QALIAS on QmgrB to point to a QCLUSTER on QmgrB. which is the MQRC_ALIAS_BASE_Q_TYPE_ERROR. The Base Q type has to be QREMOTE or QLOCAL. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Aug 24, 2012 9:03 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I specifically dislike the use of ALIAS queues in name resolution for clusters if the queue it resolves to does not reside on the same qmgr the alias queue is defined on. The chances that you get a could not resolve are too big.
Use a queue remote definition instead. It should be easier on the DLQ and put messages more likely into a transmit queue (SCTQ...)...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Aug 26, 2012 5:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
An additional attempt at clarity:
When an app (yours or WMQ internal) encounters an object name, the qmgr attempts to resolve the name.
Name resolution begins with the qmgr looking in its local object store for a matching object. It looks for a matching object name in this order QLocal, QModel, QAlias, QRemote.
If no object is found with a matching name, AND the qmgr is part of a cluster, the name resolution process next looks for a matching cluster object definition - first in the PR, then in the FR.
In your OP, the problem arose in a non-cluster qmgr - so only local objects definitions were searched. This is why a QRemote definition is needed to move a message to an xmit queue whose destination is inside the cluster.
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
