| Author |
Message
|
| girish_tharwani |
 Posted: Mon Jul 09, 2012 12:51 am Post subject: SOLVED: Overlapping cluster design issue |
 |
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
Setup
We have two overlapping cluster C1 and C2. Two qmgrs QM1 and QM2 are part of both clusters. These qmgrs are not Full Repos for any cluster. A local queue CLQ on QM1 is shared only in C1. We have a request-reply situation in which responding app conneting to QM2 is sending reply messages to CLQ on QM1.
Problem
We have noticed that if responding app ignores the ReplytoQmgr field value (ie QM1) and leaves the target qmgr as blank in reply messages, all reply messages go via C1 clusrcvr. However, reply messages go 50-50 on c1 and C2 clusrcvrs, if ReplytoQmgr field value (ie QM1) is used by responding app.
Is there a way to force all the message to go via C1 clusrcvr even when using replytoqmgr. This is needed becuase in future requsetor will be running on two legs (separate qmgrs eg QM1a and QM1b) so we need replies going back to same qmgr where the request came from so use of replytoqmgr is mandatory in design.
This issue came to our notice becuase we are using two different MCAUSERS for these two clusrcvrs on QM1 and we had given the CLQ put authority to only C1 clusrcvr's MCAUSER so half of our replies are ending in DLQ due to Auth error C2 clusrcvr's MCAUSER. And I do not want to give put access to C2 clusrcvr's MCAUSER so messages travelling on both channels is a problem.
Last edited by girish_tharwani on Tue Jul 17, 2012 10:55 pm; edited 1 time in total |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Jul 09, 2012 1:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The target queue and target queue manager name form a unique address at the time the message is put. If the message is put to a queue manager that has more than one route to that unique address, then the message will be load-balanced across the available routes.
It seems like you are attempting to use clusters to build an application-specific network - i.e. one or more sets of applications communicate with each other using CLUSTER1, and an entirely different set of applications communicate using CLUSTER2.
In order for that to be successful, you need to ensure that the applications always use cluster-specific information and NOT queue manger specific information.
So you would need to create a cluster alias for routing the reply messages. |
|
| Back to top |
|
|
| girish_tharwani |
| Posted: Mon Jul 09, 2012 2:19 am Post subject: |
|
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
| mqjeff wrote: |
The target queue and target queue manager name form a unique address at the time the message is put. If the message is put to a queue manager that has more than one route to that unique address, then the message will be load-balanced across the available routes.
|
I understand that there are two routes from QM2 to QM1 however I am not clear what makes MQ to load balance on both routes when ReplyToQmgr field value is used and what makes MQ to select only C1 ClusRcvr when ReplytoQmgr field is ignored?
| mqjeff wrote: |
In order for that to be successful, you need to ensure that the applications always use cluster-specific information and NOT queue manger specific information.
So you would need to create a cluster alias for routing the reply messages.
|
Not sure I understand it correctly  . Would you mind elaborating a littile bit. If I use cluster alias, will I not lose the ability to send the replies to same qmgr where the reqeusts came from. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 09, 2012 6:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You are using the real name of the queue manager in the replytoqmgr field.
There are two routes to that real name of the queue manager. |
|
| Back to top |
|
|
| girish_tharwani |
| Posted: Mon Jul 09, 2012 8:13 pm Post subject: |
|
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
| mqjeff wrote: |
You are using the real name of the queue manager in the replytoqmgr field.
There are two routes to that real name of the queue manager. |
Yes clear about that now.
However, still struggling for a solution. I have to put the real name of qmgr so that replies are delivered to correct qmgr and I want only one clusrcver (one path) to be used for delivery 
Any suggestions? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 09, 2012 8:52 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
To be clear, are you saying that the replying app receives multiple requests in one execution of the app?
At MOPEN for the MQPUT, does the replying application specify MQOO_BIND_ON_OPEN? Or MQOO_BIND_NOT_FIXED? Or BIND_AS_QDEF?
If BIND_AS_Q_DEF, what is the BIND queue attribute of the reply-to-queue?
_________________
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 |
|
|
| girish_tharwani |
| Posted: Mon Jul 09, 2012 9:10 pm Post subject: |
|
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
Its NOT_FIXED all over. Though I am not clear how that relates to problem at hand.
The challenge is that messages from QM2 to QM1 are using both clusrcvrs even though the destination queue is shared in one cluster (C1) only. Ask is to force messages from one C1 clusrcvr while still using the real replytoqmgr name QM1. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jul 10, 2012 12:05 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| girish_tharwani wrote: |
| The challenge is that messages from QM2 to QM1 are using both clusrcvrs even though the destination queue is shared in one cluster (C1) only. Ask is to force messages from one C1 clusrcvr while still using the real replytoqmgr name QM1. |
As stated earlier by mqjeff:
| Quote: |
| The target queue and target queue manager name form a unique address at the time the message is put. If the message is put to a queue manager that has more than one route to that unique address, then the message will be load-balanced across the available routes. |
Maybe moving to V7.5 and its separate C.T.Qs might help separate traffic down a particular route (haven't had time to play yet, so I may be barking up the wrong tree) although I doubt cluster behaviour will have changed that much between versions, or maybe play around with channel priorities etc.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 10, 2012 4:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| girish_tharwani wrote: |
| I have to put the real name of qmgr so that replies are delivered to correct qmgr |
NO.
You have to put in a unique name so that there is a unique path to the correct queue manager. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jul 10, 2012 7:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| girish_tharwani wrote: |
However, still struggling for a solution. I have to put the real name of qmgr so that replies are delivered to correct qmgr and I want only one clusrcver (one path) to be used for delivery
Any suggestions? |
Your assumption is incorrect. This is why qmgr aliases and cluster aliases do exist. Have fun. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 10, 2012 8:13 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Search here (and google) for name resolution.
_________________
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 |
|
|
| girish_tharwani |
| Posted: Fri Jul 13, 2012 4:18 am Post subject: |
|
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
| fjb_saper wrote: |
| Your assumption is incorrect. This is why qmgr aliases and cluster aliases do exist. Have fun. |
I have been working on same lines for last two days but no solution yet.
Bottomline is that:
(option 1) if QM2 has target qmgr name available (either provided by responding app explicitly in MQOD.ObjectQmgrName or I supply it via a Qmgr alias), it does not bother to resolve the target queue name. It simply load balances messages to QM2 via both available routes.
However,
(option 2) when QM2 does not have target qmgr name available (ie responding app puts MQOD.ObjectQmgrName as blank), it is forced to resolve the clustered target queue name, sees that its shared only in once cluster and then "somehow" ensures that only that cluster's channel is used for transmitting the messages. But in that case, if there are multiple instance of target queue, messages are load balanced on all of them and that I do not want (because these are reply messages and I want these routed specifically to the qmgr where the request came from thus the option 1)
Option 1 may be as designed feature of WMQ but it does not seem right that even if a queue is shared explictly in one cluster only, other clusters channels are used for communication and probably that's what they are trying to improve by mulitple SCTQs of v7.5.
If I am missing something which can solve this issue, until we move to v7.5, please help. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 13, 2012 7:42 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What you are missing:
Create a qmgr alias that is only shared in 1 cluster.
Use the qmgr alias as the reply to qmgr.
Resolving to local qmgr is done by the qmgr alias.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| girish_tharwani |
| Posted: Sun Jul 15, 2012 7:48 pm Post subject: |
|
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
| fjb_saper wrote: |
What you are missing:
Create a qmgr alias that is only shared in 1 cluster.
Use the qmgr alias as the reply to qmgr.
Resolving to local qmgr is done by the qmgr alias.
Have fun |
Thanks fjb_saper. It should work (will try it today).
But being devil's advocate...
Typically when I design a system, I avoid asking requesting app to populate the "ReplyToQmgr" field. I let MQ fill it when the request message leaves the requestor side qmgr (QM1). This helps when requesting app is running on two nodes connecting to two qmgrs (say QM1a and QM1b). MQ populate the appropriate name without app worrying about it. To implement this alias solution, I will have to create aliases (say QM1a.C1 and QM1b.C1) and ask app to populate these. Which means app needs to have two different config files on two nodes (assuming it stores replytoqmgr info in a config file).
Though I can circumvent this problem by keeping the alias names same as qmgr names (ie QM1a and QM1b) but that may cause issues/confusions in long run. If the aliases are for specific cluster routing, I want the alias names to reflect it and I do not want these aliases to be interfering with cluster C2's functioning. Tomorrow I may want to implement something similar for C2 and at that time having cluster names embedded in alias names will simplify the naming pattern. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jul 15, 2012 8:30 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| girish_tharwani wrote: |
But being devil's advocate...
|
I don't see you in the role of devil's advocate here. Rather, you appear to still be confused with some of the basics of name resolution.
Your design extends the usual (and simple) request-reply model. In the usual model, the app only seeds the reply-to-queue name; and the qmgr puts its own name in the reply-to-qmgr field. On the replying qmgr, there needs to be an xmitq with the same name as the requesting qmgr.
You have added an additional requirement to have explicit control of the path the reply takes back to the requesting qmgr. This is typically done with the app specifying both reply-to-q and reply-to-qmgr fields; and the reply-to-qmgr name would identify an alternate xmit queue for the return trip. This alternative qmgr name must be resolved. This resolution is typically done with a qmgr-alias.
Both of these scenarios, with sample definitions, are well-documented in the WMQ Intercommunications manual (and InfoCenter equivalent).
Use of aliases in clusters is also nicely documented in the WMQ Queue Manager Clusters manual (and InfoCenter equivalent). Look for this section title "Using aliases and remote-queue definitions with clusters"
_________________
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 |
|
|
|
|
