| Author |
Message
|
| mqmike |
 Posted: Wed Aug 18, 2004 5:09 am Post subject: Reply-to-queue and reply-to-qmgr |
 |
|
Acolyte
Joined: 09 Jul 2004
Posts: 63
|
Currently we have one qmgr accessing another via an MQ hub - ie multihopping. QMGR A has 2 remote queues which go via QMGR B (the hub) to the backend, QMGR C. A reply message is generated on QMGR C, put on to a remote queue and this goes back to QMGR A.
There is a requirement to provide DR for QMGR A so we are looking at building another QMGR to access the backend, QMGR C.
The application at the backend is currently hard coded to put all replies on to one remote queue which points back to QMGR A. We want to be able to have all replies going back to the QMGR which issued the request.
I guess the application needs to be change to use reply-to-qmgr and reply-to-queue fields instead of a hard coded queue, but I'm not sure how to do this. Do we set up two qmgr aliases on QMGR C and let the application pick up the fields? Will the application use the qmgr alias if a reply-to-queue has also been specfied? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Aug 18, 2004 7:01 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Let's say you specified reply to (queue and qmgr) on your message.
Now the message comes from either qm1 or qm2 goes through the hub and ends up on qm3.
You can specify 2 qmgr aliases on qm3: 1 for qm1 and 1 for qm2, both pointing to the transmission queue to the hub.
Now I would expect that the hub will know how to route to either qm1 or qm2.
This should do the trick for you.
Enjoy  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 18, 2004 7:08 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Or QM3 can have its default transmit queue be the xmit queue back to the hub. This way you dont need a queue manager alais for every spoke QM on every spoke QM.
Default transmit queues are perfect for Hub and Spoke architectures. Just make sure the Hub QM's default transmit queue is NOT set, to prevent endless loops. But every spoke QM's default transmit queue can point to the Hub.
We have been running like this for years, with dozens of spokes.
Saves a lot of effort whenever we add a new spoke QM. All existing QMs can talk to the new guy with no changes on them.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Aug 18, 2004 7:51 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
I hate the concept of 'Default Transmission' queue. Until you have spent hours and hours and hours... trying to debug a simple mistake like:
- QMgrA -> QMgrB
- QMgrB -> QMgrHub
- QMgrC -> QMgrD
- QMgrD -> QMgrHub
- QMgrE -> QMgrF
- QMgrF -> QMgrHub
- QMgrG -> QMgrH
- QMgrH -> QMgrG
1 simple queue manager alias is so much clearer than having having the default transmit set.
That's my 2 cents.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| mqmike |
| Posted: Thu Aug 19, 2004 1:44 am Post subject: |
|
|
Acolyte
Joined: 09 Jul 2004
Posts: 63
|
Thanks guys all good stuff. Default x-mitq info v useful as well.
Just to confirm then:
When reply-to-queue and reply-to-qmgr are specified in the MQMD and the application uses these fields, it will hit the qmgr alias and resolve the queue name later, once it arrives on the target destination.
In this example I guess the application which initially sends the request/response needs to make sure it includes the reply-to-queue field in any message? At the moment I don't think it's doing this. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Aug 19, 2004 7:17 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| You do not need a qmgr alias. If the ObjectQMgr in the MQOD is the name of an xmitq, then the msg will be put onto that xmitq. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Aug 19, 2004 3:59 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Roger, anything in life setup improperly can be a source of confusion, but that doesn't make it bad. Someone could have set up a RemoteQ called QueueA on QM1 that points to QueueB on QM2. And QueueB is a remote queue that points back to QueueA. Where's my message?!? Now, that doesn't mean you shouldn't use remote queues, does it?
| Quote: |
1 simple queue manager alias is so much clearer than having having the default transmit set.
|
If all I had to create was 1 QM Alias, then its a toss up. But I have 30 spoke QMs. For each one to talk to each other would 30 x 30 = (hold on I gotta take off my socks so I can use my toes) 900 QMAliases! A lot easier to use Default XMITQs.
| Quote: |
In this example I guess the application which initially sends the request/response needs to make sure it includes the reply-to-queue field in any message?
|
Yes it does.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Aug 19, 2004 8:06 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Tsh, tsh, tsh... Peter,
You are mixing and matching your terms to jusitfy your arguement. 
You say you have a spoke topology but you use star topology when quoting "how many QMgr Aliases' will need to be created. You can't have your cake and eat it too. 
If you have a spoke topology then you define either:
- 30 QMgr Aliases to the hub OR
- 30 Default XMITQs
Because there is a hub and all message will two-hop to their destination.
I generally don't recommend star topolog but to go with your example of 30 x 30 QMgr Aliases, this implies direct connection between EACH and EVERY queue manager. Therefore, you would need the 30 Default XMITQs plus another 870 QMgr Aliases to complete the direct connections. Otherwise you are NOT comparing 'apples' to 'apples'. Because just saying 30 Default XMITQs does NOT give you star topology.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Aug 20, 2004 1:42 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Never heard the term star.....How is that different from Hub-n-Spoke?
Anyway...
I have a HUBQM, and 30 spoke QMs (SpokeQM1...SpokeQM30)
All the Spoke QMs have only 1 channel pair, to and from the HUB. If you do not use Default XMITQs on the SpokeQMs, and you want every Spoke QM to be able to send a message to any other Spoke QM, via the HUB, you will need 900 QMAliases in total.
SpokeQM1 needs the following QMAlaises: SpokeQM2, SpokeQM3....SpokeQM29, SpokeQM30. A total of 29.
SpokeQM2 needs the following QMAlaises: SpokeQM1, SpokeQM3....SpokeQM29, SpokeQM30. A total of 29.
etc
etc
30 (SpokeQMs) x 29 (QMAliases each) = 870 QM Alaises.
Then on the HUBQM, you need 30 QMAliases, one for each Spoke QM.
That is why a Hub and Spoke topology with 30 SpokeQMs and no default XMITQs needs 900 QMAliases. But if you use Default XMITQs, then you only need 30 QMAliases on the HUBQM, and no QMAliases on the SpokeQMs.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Aug 20, 2004 2:11 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hummm, I had this long explanation typed in and then it dawned on me where you are coming from. Your spoke applications connecting to their local spoke queue manager want to directly put messages to another spoke queue manager by specifying BOTH the queue manager name and the queue name.
I guess if you don't use a router then using the Default XMITQ is reasonable.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
