| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Cluster, qmgr alias, and reply-to queues |
« View previous topic :: View next topic » |
| Author |
Message
|
| leot |
 Posted: Wed Sep 24, 2003 9:17 am Post subject: Cluster, qmgr alias, and reply-to queues |
 |
|
Novice
Joined: 21 Apr 2002
Posts: 24
Location: NYC
|
I have a problem (which may be of my own making), and would greatly appreciate any help in resolving it.
Setup:
QM1 - cluster qm, with Q.COD defined as local clustered queue;
QM2 - cluster qm, with Q.COD defined as local clustered queue;
QM.GWY - cluster gateway; has GWY defined as qm alias. It's the only qm in the cluster that has sender/receiver channel and remote queue definitions.
QM.OTHER - remote qm, to which the gateway has sender/receiver, and from which I want COD's; has xmit queue QM.GWY (equal to the name of its' partner qm)
I am trying to send a message out of a cluster, and receive COD back into the same cluster. Question: what do I specify as reply-to info?
What I tried so far:
1) replyto.qm=GWY; replyto.q=Q.COD.
This works only if xmit queue QM.GWY on QM.OTHER is defined as _default_ xmit queue. If it's not - QM.OTHER cannot resolve the replyto name "GWY", and my COD ends up on QM.OTHER's dlq. I don't like tying a queue manager to any particular partner qm by setting a default xmit queue.
2) replyto.qm=QM.GWY; replyto.q=Q.COD.
This lets QM.OTHER resolve replyto qm "QM.GWY" to xmit queue with the same name; since that xmit queue is being used as _the_ xmit queue for the sender channel from QM.OTHER to QM.GWY - the COD message makes it to the QM.GWY, but there it goes on its dlq, because, I guess, the QM.GWY expects to find a local queue "Q.COD" and cannot decide which one to pick (they are all cluster queues, and there is more than one available for QM.GWY!);
3) replyto.qm=QM.GWY; replyto.q=Q.COD.local.
With Q.COD.local added as local queue to QM.GWY everything works - QM.OTHER resolves "QM.GWY" as its xmit queue name; that xmit queue is used by sender channel from QM.OTHER to QM.GWY, and therefore COD message makes it onto QM.GWY; QM.GWY sees "QM.GWY" as the "to-qm", and "Q.COD.local" as the "to-queue", and places it there. BUT - it defeats the purpose of the cluster! I would like the COD message to make it into the cluster somehow (QM1 and QM2), and not get processed by the gateway.
Is there any "trick" I could use, or am I missing something really simple?
Thanks
- Leonid |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Sep 24, 2003 1:01 pm Post subject: Re: Cluster, qmgr alias, and reply-to queues |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| leot wrote: |
1) replyto.qm=GWY; replyto.q=Q.COD.
This works only if xmit queue QM.GWY on QM.OTHER is defined as _default_ xmit queue. If it's not - QM.OTHER cannot resolve the replyto name "GWY", and my COD ends up on QM.OTHER's dlq. I don't like tying a queue manager to any particular partner qm by setting a default xmit queue.
|
I wouldn't think this would work unless GWY was defined as a qmgr alias on QM.OTHER, or as you say if the default xmit queue goes to QM.GWY.
| leot wrote: |
2) replyto.qm=QM.GWY; replyto.q=Q.COD.
This lets QM.OTHER resolve replyto qm "QM.GWY" to xmit queue with the same name; since that xmit queue is being used as _the_ xmit queue for the sender channel from QM.OTHER to QM.GWY - the COD message makes it to the QM.GWY, but there it goes on its dlq, because, I guess, the QM.GWY expects to find a local queue "Q.COD" and cannot decide which one to pick (they are all cluster queues, and there is more than one available for QM.GWY!);
|
This should work. What is the reason given in the dead letter header when messages go to the DLQ?
| leot wrote: |
3) replyto.qm=QM.GWY; replyto.q=Q.COD.local.
With Q.COD.local added as local queue to QM.GWY everything works - QM.OTHER resolves "QM.GWY" as its xmit queue name; that xmit queue is used by sender channel from QM.OTHER to QM.GWY, and therefore COD message makes it onto QM.GWY; QM.GWY sees "QM.GWY" as the "to-qm", and "Q.COD.local" as the "to-queue", and places it there. BUT - it defeats the purpose of the cluster! I would like the COD message to make it into the cluster somehow (QM1 and QM2), and not get processed by the gateway.
|
Instead of defining Q.COD.local as a local queue you could define it as an alias to Q.COD in the cluster. That might work...?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 24, 2003 5:46 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
You are real close Leonid. Here is what you need to do.
Get rid of Q.COD.local.
If you want to, get rid of the DEFXMIT queue attribute for QM.Other.
On QM.Other, define a QMAlias for every QM in the cluster. So on QM.Other you would have the following QMAliases:
QueueName=QM1, RemoteQueueName = ( ), RemoteQueueManagerName = QM1, Transmit queue = "QM.GWY"
QueueName=QM2, RemoteQueueName = ( ), RemoteQueueManagerName = QM2, Transmit queue = "QM.GWY"
QueueName=QM.GWY, RemoteQueueName = ( ), RemoteQueueManagerName = QM.GWY, Transmit queue = "QM.GWY"
(Actually this last one is redundant if you have a transmit queue called exactly QM.GWY, but it won't hurt. And it allows you to change the name of the XMIT queue if you like)
Now when an app on QM1 or QM2 puts the request message, it only specifies Q.COD in the Reply2Queue field. Leave the Reply2QueueManager field blank. A queue manager will always fill in this field with its own name if you leave it blank.
When the message reached QM.OTHER's queue, the COD message is sent, looking for Q.COD on QM1 (or QM2). QM.OTHER has that QMAlias, so the first thing that will happen is the message will get routed via that QMAlias to the QM.GWY transmit queue over to QM.GWY.
Now the message is on QM.GWY, looking for a queue manager called QM1. QM.GWY knows about QM1, sees that this message is specifically for QM1, and thus sends it to QM1, where it gets placed to Q.COD. 
We do this all the time, in much more complicated layouts (overlapping clusters, multiple channels between the gateway QM and the outside QM, etc) and it works perfectly. Make sure you are at 5.3, because there were bugs in some of the 5.2.1 versions where this would not work. IBM provided us efixes until we got to 5.3.
(Also you should have a QMAlias on QM.Other named after your cluster name (lets call it Cluster1). The definition would be as follows:
QueueName=Cluster1, RemoteQueueName = ( ), RemoteQueueManagerName = ( ), Transmit queue = "QM.GWY"
What this will allow is apps on QM.OTHER to put messages specifying a Queue Manager name of Cluster1 on their MQOpen call. The QMAlias will catch those messages, remove the Cluster1 from the destination QM in the MQMD, and send it over to QM.GWY. Once at QM.GWY, the message are free to cluster around since they are no longer looking for a QM called Cluster1. They are not looking for any QM at all, so they are free to round robin.)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| leot |
| Posted: Thu Sep 25, 2003 4:36 am Post subject: |
|
|
Novice
Joined: 21 Apr 2002
Posts: 24
Location: NYC
|
Thanks for such a detailed answer!
Your suggestion, though, may be less than ideal for my particular situation - I forgot to mention (of course  !) that the clustered qm's on one hand, and QM.OTHER on the other, belong to two entirely different organizations (mine being the "clustered" one), and the less one side knows about the other, the better.
So, in my (maybe idealistic) view, the most the QM.OTHER's side knows about the cluster side is: qm name and channel to connect to, and queue name to use. They should not really know about the cluster at all. And I was hoping that COD communication would not require any additional knowledge on part of QM.OTHER about the cluster's side. Was I wrong?
Thanks,
- Leonid |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 25, 2003 5:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
QM.OTHER will need the DEFXMIT parameter turned on to point to QM.GWY.
If you do this, you can get rid of all the QMAliases on QM.OTHER. Any messages that have a destination queue manager name in the header of QM1, QM2, QM.GWY or Cluster1 will get to QM.GWY because of that XMIT queue.
Messages with QM1, QM2 or QM.GWy will work as I described above.
Messages that you want to round robin in the cluster will be arriving at QM.GWY with a destination queue manager name of Cluster1. These will go to the DLQ, since there is no QM called Cluster1 in your cluster. The way to fix this is to make a QMAlias on QM.GWY like this:
QueueName=Cluster1, RemoteQueueName = ( ), RemoteQueueManagerName = ( ), Transmit queue = ( )
What this will do is catch any messages looking for a QM called Cluster1, and make them look for no specific QM at all. At that point, they are free to round robin in the cluster.
This method assumes QM.OTHER is willing to set it's DEFXMIT value to QM.GWY. Its one or the other. Either QM.OTHER sets its DEFXMIT queue to QM.GWY, or it has to define all the QMAliases. It will not work any other way.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| leot |
| Posted: Fri Sep 26, 2003 9:28 am Post subject: |
|
|
Novice
Joined: 21 Apr 2002
Posts: 24
Location: NYC
|
The "other" side eventually chose yet another way - IMHO, less transparent to them, but see for yourself:
4) they set up a remote queue def on QM.OTHER, called Q.OTHER.COD, pointing to QM.GWY/Q.COD. Then they requested that reply-to fields in the messages QM.GWY sends to QM.OTHER are set: qm=QM.OTHER; q=Q.OTHER.COD.
This definitely works, but is not too transparent: both sides need to know a great deal about each other's setup.
Thanks again for your input!
- Leonid |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 26, 2003 10:30 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
This a lame solution!
So the messages will get to QM.GWY, looking for a queue called Q.COD, that lives on QM.GWY only. If they find Q.COD local to QM.GWY, the messages go there. If not, they go to the DLQ. Note that even if QM1 and QM2 host clustered version of Q.COD, and QM.GWY wont send the messages to them, because the messages are tagged as looking for Q.COD on QM.GWY only.
And to make it work in this lame way, they are asking you to have to fill in the Reply2QueueManager with THEIR queue manager name. Talk about convoluted! 
Fight to make it right! Present them one of the 2 solutions above and ask them to choose one.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
