Peter, I agree ...
And as I told before, I will address this on our next GSE meeting in May - maybe it helps ... Regards Hubert > -----Ursprüngliche Nachricht----- > Von: MQSeries List <[email protected]> > Gesendet: 07.03.08 17:03:14 > An: [email protected] > Betreff: Re: Overlapping clusters and cluster channels used > > "But if IBM would accept the requirement I guess your applications would also > have to be modified" > > Mine wouldn't. For now I'm just dealing with the reply messages mixing across > both clusters' channels. The separate clusters are not for security reason > but for squeezing every last bit of performance out and this is only a > problem for 1 hop out of many. My apps use regular reply queues and reply to > QMs so the fix would help me out with no changes. > > But yeah, for anyone that did implement the Reply To Alias + special cluster > specific Reply QM alias definitions it could force a change for them if a fix > went in. Or not, depending how it was implemented. Maybe an optional switch > or something. > > Peter Potkay > > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Hubert Kleinmanns > Sent: Friday, March 07, 2008 10:01 AM > To: [email protected] > Subject: Re: Overlapping clusters and cluster channels used > > Peter, > > you are right, live is not always that easy ;-). > > But if IBM would accept the requirement I guess your applications would also > have to be modified :-( > > Regards > Hubert > > > -----Ursprüngliche Nachricht----- > > Von: MQSeries List <[email protected]> > > Gesendet: 07.03.08 15:32:04 > > An: [email protected] > > Betreff: Re: Overlapping clusters and cluster channels used > > > > > > OK, gotcha, that is a little simpler. And its not that bad if you have a > > brand new infrastructure waiting for the 1st app to come in. > > > > I have 200 Apps in ClusterA and 3 in the new ClusterB. The apps that need > > to use ClusterB are the special case and they are just told to use the > > Reply To Queue Alias method. But then I have to go back to the 200 other > > apps and make them all change and test as well? Most of you know that is a > > LOT easier said than done. And build a few hundred Alias defs? Ack! > > > > So while I'll tuck this method into my back pocket as "workaround", I > > personally consider this a small deficiency in MQ (its just my opinion). > > Ideally adding more routing info to a message (a Reply2QM) should not > > introduce randomness in message delivery in overlapping clusters. > > > > Thanks Neil for taking the time to detail out your solution, er, I > > mean workaround. :-D > > > > > > Peter Potkay > > > > > > -----Original Message----- > > From: MQSeries List [mailto:[EMAIL PROTECTED] On > > Behalf Of Neil Casey > > Sent: Thursday, March 06, 2008 5:29 PM > > To: [email protected] > > Subject: 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(tm) | 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. > > > > 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 > -- 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
