Peter, Neil describes very detailed, what I meant. In short: You do not have to empty the ReplyToQMgr field, but to set it to a cluster specific "virtual" QMgr name. Additionally you have to define a non-clustered QMgr alias, which maps the "virtual" QMgr name back to the real QMgr name.
The application has to be modified, to support ReplyToQ aliases, but then you are very flexible to configure your environment. And REPLY queues should (normally) never be defined as cluster queues, because MQ first routes the message to the QMgr and then (when the message arrived on the target QMgr) it resolves the queue. Last but not least, I also hope that the routing follows the QMgr alias definitions and not the real QMgr definitions (and so uses the correct cluster channels). Otherwise this would be a bug, not a feature ;-). Regards Hubert > -----Ursprüngliche Nachricht----- > Von: MQSeries List <[email protected]> > Gesendet: 06.03.08 23:29:16 > An: [email protected] > Betreff: Re: Overlapping clusters and cluster channels used > > Hi Peter, > > I think you may have misunderstood a capabiility, and may be overstating > the difficulty of getting correct routing to work. > > You should not need to have a separate cluster visible replyToQ for each > instance of the application. You should be able to use the replyToQ alias > to drive the responses down the correct cluster channel. > > There are some pre-conditions needed to make this work, and an application > architecture change as well, but I believe that it should be feasible to > implement correct cluster routing of responses in the following way. > > On each of the queue manager that a requesting application is running > against... > 1. Change all requesting apps to separate the name of the replyToQ named in > the request MQMD from the queue which is opened to receive the reply. The > ReplyToQ in the request message MQMD should be set to APP1.REPLYQ.CL1 or > APP1.REPLYQ.CL2. The application then opens APP1.REPLYQ to receive the > reply message. > 2. Create cluster queue manager aliases for each queue manager, which > points to itself, and which is visible only in one cluster. IE. for queue > manager QM1, which is in clusters CL1 and CL2... > define qr(QM1.CL1) rqmname(QM1) cluster(CL1) > define qr(QM1.CL2) rqmname(QM1) cluster(CL2) > 3. Create reply queues which are local (not clustered) > define ql(APP1.REPLYQ) > 4. Create replyToQ aliases on the source server, which designate the > cluster to be used for the reply > define qr(APP1.REPLYQ.CL1) rqmname(QM1.CL1) rname(APP1.REPLYQ) > define qr(APP1.REPLYQ.CL2) rqmname(QM.CL2) rname(APP1.REPLYQ) > > There should not need to be any change to the server application. MQ will > populate the replyToQMgr alias, and that should drive the correct response > channel. > > Note: this depends on correct behaviour of MQSeries when choosing a channel > to respond with a cluster visible queue manager alias. There has been a bug > in past versions of MQ where any cluster channel to the correct queue > manager could be chosen, rather than only channels in the same cluster. I > do not know whether this problem has been fixed, as I haven't had time to > build a test rig to try it out. > > Regards, > > Neil Casey. > ____________________________________________________________________________________________________________ > > Neil Casey| Lead Technical Specialist - Systems Management Group | Atlas > Technology Services | nabCapital⢠| A division of National Australia Bank > Limited > Office: +61 3 8641 1068 | Mobile: 0438 573 152 | Fax: +61 3 8641 4699 | > Email: [EMAIL PROTECTED]| Location: Level 24, 500 Bourke Street, > Melbourne > Intranet Portal: > http://intranet.global.thenational.com/Units/Services/Technology/ATLAS/AppSer/SysMan/Pages/default.aspx > > > > > "Potkay, Peter M > (ISD, IT)" > <[EMAIL PROTECTED] To > HARTFORD.COM> [email protected] > Sent by: MQSeries cc > List > <[EMAIL PROTECTED] Subject > V.MEDUNIWIEN.AC.A Re: Overlapping clusters and > T> cluster channels used > > > 03/07/2008 06:34 > AM > > > Please respond to > MQSeries List > <[EMAIL PROTECTED] > V.MEDUNIWIEN.AC.A > T> > > > > > > > I don't think ReplyTo Queue Aliases will help, unless you are willing to > have each instance of the app on the various servers running with a unique > config file that allows each one to use a unique q name for the reply > message. In that case the requesting app uses the Reply To Q Alias on the > put of the request message, the alias makes sure the request message is > sent with nothing in the Reply To QM and a unique name in the Reply To > Queue. So when the responding app does its put of the reply message its > sent with nothing in the Reply To QM field. And now the messages will > travel exclusively over the channels that are the same cluster as the > unique reply queue that exists on only 1 QM in only 1 cluster. > > BUT, now every app needs to be configured this way. All the apps that use > ClusterOne need to use this method to insure their messages to do not use > any channels in the other overlapping clusters, and all the apps that use > queues in the other clusters need to use this method to insure their > messages do not try to use ClusterOne's channels. > > An app putting a message to reply q name only (no reply QM) in overlapping > clusters uses the correct cluster channels. As soon as I add more info for > more specific routing (I add a Reply QM) MQSeries introduces randomness on > how that message gets to the Reply QM? And the only way around it is for me > to define hundreds of Reply To Queue Aliases and apps that run on multiple > QMs in the clusters need to have a unique configuration on each of those > QMs? > > I'm sorry but that just ain't right. Fix MQ name resolution to respect > overlapping clusters I say. If a QM knows its in 2 or more clusters it > should know not to give up on name resolution just because a destination QM > is found early on in the name resolution process. > > > Peter Potkay > > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf > Of Hubert Kleinmanns > Sent: Thursday, March 06, 2008 1:58 AM > To: [email protected] > Subject: Re: Overlapping clusters and cluster channels used > > Peter, > > ReplyToQ aliases would be the way I would go, but I agree that it would be > nice when messages route back using the correct channels. At the moment I > do not see, how this could happen. How should the reply message "know" > about the cluster channels, it has to go? > > Maybe you need a sort of "ReplyToCluster" attribute in the request message. > Perhaps this (optional) attribute could be filled in automatically when a > cluster queue has been resolved on the MQOPEN call (eventually with a new > OPEN option). > > As a chairman of the german's MQ user group of the Guide Share Europe > (GSE), I would like to address this on our next working group meeting. > Possibly I would be able to make a requirement at IBM via the GSE. > > Regards > Hubert > > > > > -----Ursprüngliche Nachricht----- > > Von: MQSeries List <[email protected]> > > Gesendet: 05.03.08 18:46:38 > > An: [email protected] > > Betreff: Re: Overlapping clusters and cluster channels used > > > > > > I sent in a requirement for the below. > > > > Got back "It is unlikely this will be implemented; while it's > > inconvenient to change application code, this would be the recommended > > approach." > > > > Boooooo! > > > > If anyone else out there thinks this would be a good idea shoot me an > > email and I'll send you my requirements form that has a lengthy and > > detailed explanation why I think adding a QM name to an MQOPEN call in > > overlapping clusters shouldn't introduce randomness on how messages > > are delivered (over using the q name alone). You then just have to > > forward it on to the requirements team email (address is in the form). > > > > Like T.Rob says the more people that request something the more likely > > it is to happen. > > > > > > Peter Potkay > > > > > > -----Original Message----- > > From: MQSeries List [mailto:[EMAIL PROTECTED] On > > Behalf Of Potkay, Peter M (ISD, IT) > > Sent: Thursday, February 14, 2008 9:51 AM > > To: [email protected] > > Subject: Re: Overlapping clusters and cluster channels used > > > > Yup, your going down the path I was with the Aliases. But it presumes > > the requesting app has to now set a specific value for the Reply To > > Queue Manager, instead of leaving it blank and letting the QM > > automagically fill it in. I depend on that behavior because the app > > (Websphere Message Flows in this case) can run on multiple QMs. I will > > have to either make the flows add code that query what QM they are > > connected to (I assume that's possible), and then append the proper > > suffix depending on which QM in which environment they are in (big > > CASE statement). Or use Reply To Aliases in conjunction with the QM > Aliases. > > That's why I said convoluted. Its tuff enough explaining the routing > > in overlapping clusters to customers. Adding ReplyTo Aliases and QM > > Aliases on top of that, oh boy. I was hoping for another way. > > > > While I agree its working as designed when it comes to routing when a > > QM name is present, do you think that's the way it *should* be? Would > > it be bad for a QM that was routing messages in overlapping clusters > > to check the q name as well as the QM name if it checks the q name > > anyway when only the q name is provided? If everyone says it's a bogus > > idea I'll make due with Aliases. But if you all think it makes sense > > I'll open an enhancement request. > > > > > > Peter Potkay > > > > > > -----Original Message----- > > From: MQSeries List [mailto:[EMAIL PROTECTED] On > > Behalf Of T-Rob > > Sent: Wednesday, February 13, 2008 5:04 PM > > To: [email protected] > > Subject: Re: Overlapping clusters and cluster channels used > > > > Peter, > > > > The flaw in your theory, I believe, is that it presumes that the name > > resolution ever gets to the queue object. I believe that once name > > resolution determines that the QMgr is not local and that there is a > > route, it attempts to deliver the message accordingly. So it never > > "sees" > > that the queue is in one cluster or the other This is why you can > > send messages to queues that are not advertised in the cluster as long > > as you fully qualify the name. What you have to do is make the *QMgr* > > resolve to a particular cluster. > > > > I don't know how convoluted you think this approach is but you can > > make a QMgr alias like this: > > > > On QM1 > > DEF QA(CLUSTER1.QM1) RNAME( ) RQMNAME( ) XMITQ( ) CLUSTER(CLUSTER1) > > > > On QM2 > > DEF QA(CLUSTER1.QM2) RNAME( ) RQMNAME( ) XMITQ( ) CLUSTER(CLUSTER1) > > > > On QM3 > > DEF QA(CLUSTER1.QM3) RNAME( ) RQMNAME( ) XMITQ( ) CLUSTER(CLUSTER1) > > > > On QM4 > > DEF QA(CLUSTER1.QM4) RNAME( ) RQMNAME( ) XMITQ( ) CLUSTER(CLUSTER1) > > > > Then use CLUSTER1.QM? as the reply-to QMgr name. This resolves the > > logical QMgr in a particular cluster even though the physical QMgr is > > in both. > > -- T.Rob > > > > > > MQSeries List <[email protected]> wrote on 02/13/2008 > > 03:24:00 PM: > > > > > QM1, QM2, QM3 and QM4 are all in the same 2 overlapping clusters. > > > Lets call them CLUSTER1 and CLUSTER2. Each QM has 2 CLUSRCVR > > > channels, one clustered to each cluster. Same thing with their > > > CLUSSNDRs to the Full Repositories: 2 each and each one is clustered > > > to the specific cluster its for. The Full Repositories use namelists > > > to identify both of these cluster names so the FRs can be FRs for > > > both > > > > > clusters. > > > On QM1 and QM2 there is a local clustered q called THIS.QUEUE.1.2. > > > Its clustered to CLUSTER1 only. > > > On QM3 and QM4 there is a local clustered q called THAT.QUEUE.3.4. > > > Its clustered to CLUSTER1 only. > > > When an app connected to QM3 or QM4 does a MQPUT to THIS.QUEUE.1.2 > > > there is no problem. Load balancing works. Same thing in reverse. > > > When an app connected to QM1 or QM2 does a MQPUT to THAT.QUEUE.3.4 > > > load balancing works as well. In both cases the apps don't specify a > > > QM name in the MQOPEN or MQPUT1. And I see the channels clustered to > > > CLUSTER1 moving all this traffic. > > > Here's the problem: > > > In the above scenario, when the app DOES specify the QM name in the > > > MQOPEN or MQPUT1, the message does make it to the specific instance > > > of > > > > > the queue, but it looks like some of the messages go over a channel > > > in > > > > > CLUSTER1, and some messages use the CLUSTER2 channel. > > > That's not good. If the destination q is in CLUSTER1 I need the > > > message to use the CLUSTER1 channels only. > > > It seems that when a destination QM name is used the cluster > > > workload algorithm on the sending QM sees the destination QM is a > > > member of both clusters and ignores the fact that the destination q > > > is in only one of the clusters, a so produces messages onto the S.C. > > > T.Q. that are eligible for either cluster's channels. > > > Any ideas how to get around this? I came up with a real convoluted > > > way > > > > > that might work using QM Aliases and ReplyTo Aliases but hope to > > > avoid > > > > > that. Is it a bug that both clusters' channels are being used in > > > this scenario? > > > > > > Peter Potkay > > > > > > > > > > > ********************************************************************** > > ** > > * > > > This communication, including attachments, is for the exclusive use > > > of > > > > > addressee and may contain proprietary, confidential and/or > > > privileged information. If you are not the intended recipient, any > > > use, copying, disclosure, dissemination or distribution > > is > > > strictly prohibited. If you are not the intended recipient, please > > notify > > > the sender immediately by return e-mail, delete this communication > > > and > > > > > destroy all copies. > > > > > ********************************************************************** > > ** > > * > > > > > > > > List Archive - Manage Your List Settings - Unsubscribe Instructions > > > for managing your mailing list subscription are provided in the > > > Listserv General Users Guide available at > > http://www.lsoft.com > > > > To unsubscribe, write to [EMAIL PROTECTED] and, in > > the message body (not the subject), write: SIGNOFF MQSERIES > > Instructions for managing your mailing list subscription are provided > > in the Listserv General Users Guide available at http://www.lsoft.com > > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > > > > ********************************************************************** > > ** > > * > > This communication, including attachments, is for the exclusive use of > > addressee and may contain proprietary, confidential and/or privileged > > information. If you are not the intended recipient, any use, copying, > > disclosure, dissemination or distribution is strictly prohibited. If > > you are not the intended recipient, please notify the sender > > immediately by return e-mail, delete this communication and destroy all > copies. > > ********************************************************************** > > ** > > * > > > > To unsubscribe, write to [EMAIL PROTECTED] and, in > > the message body (not the subject), write: SIGNOFF MQSERIES > > Instructions for managing your mailing list subscription are provided > > in the Listserv General Users Guide available at http://www.lsoft.com > > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > > > > ********************************************************************** > > *** This communication, including attachments, is for the exclusive > > use of addressee and may contain proprietary, confidential and/or > > privileged information. If you are not the intended recipient, any > > use, copying, disclosure, dissemination or distribution is strictly > > prohibited. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this communication and > > destroy all copies. > > ********************************************************************** > > *** > > > > To unsubscribe, write to [EMAIL PROTECTED] and, in > > the message body (not the subject), write: SIGNOFF MQSERIES > > Instructions for managing your mailing list subscription are provided > > in the Listserv General Users Guide available at http://www.lsoft.com > > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > > -- > Hubert Kleinmanns > Beratung / Schulung / Projektleitung > > Chairman der WG "WebSphere MQ and Business Integration" in der GSE, deutsche Region. > > > Tel.: +49 (0) 60 78 / 7 12 21 > Fax: +49 (0) 60 78 / 7 12 25 > Mobil: +49 (0) 178 / 6 97 22 54 > Web: www.kleinmanns.eu > GSE: www.gsenet.de > > To unsubscribe, write to [EMAIL PROTECTED] and, in the > message body (not the subject), write: SIGNOFF MQSERIES Instructions for > managing your mailing list subscription are provided in the Listserv > General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > ************************************************************************* > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > ************************************************************************* > > To unsubscribe, write to [EMAIL PROTECTED] and, > in the message body (not the subject), write: SIGNOFF MQSERIES > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > National Australia Bank Ltd - ABN 12 004 044 937 > This email may contain confidential information. If you are not the intended > recipient, please immediately notify us at [EMAIL PROTECTED] or by replying to > the sender, and then destroy all copies of this email. Except where this email > indicates otherwise, views expressed in this email are those of the sender > and not > of National Australia Bank Ltd. Advice in this email does not take account of > your > objectives, financial situation, or needs. It is important for you to > consider these > matters and, if the e-mail refers to a product(s), you should read the > relevant > Product Disclosure Statement(s)/other disclosure document(s) before making any > decisions. If you do not want email marketing from us in future, forward this > email > with "unsubscribe" in the subject line to [EMAIL PROTECTED] in order to > stop marketing emails from this sender. National Australia Bank Ltd does not > represent that this email is free of errors, viruses or interference. -- Hubert Kleinmanns Beratung / Schulung / Projektleitung Chairman der WG "WebSphere MQ and Business Integration" in der GSE, deutsche Region. Tel.: +49 (0) 60 78 / 7 12 21 Fax: +49 (0) 60 78 / 7 12 25 Mobil: +49 (0) 178 / 6 97 22 54 Web: www.kleinmanns.eu GSE: www.gsenet.de To unsubscribe, write to [EMAIL PROTECTED] and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
