Hubert, Sorry for the delay - I've been on leave.
I'm not sure what you want me to explain or in fact what your concern is. Bear in mind that MQ does its routing in two stages. If the QM is not local all it cares about is how to get to the QM. If the QM is local then it routes to the individual queue. So, if you're targetting a remote QM (via a remote queue if necessary) all MQ will concern itself with is "do I know how to get to this remote QM". We don't care what the target queue name is and therefore don't need a cluster definition of it. This is the same principle temporary reply queues work and why you don't need a remote queue definition for each remote queue your sending messages to. Anyway, presumably you have a cluster queue manager telling MQ how to get to your remote QM so off it goes. Clustering is still very useful to send messages to non-cluster queues and just using it as a way to manage the channel definitions etc. Does this clarify at all ? Cheers, P. Paul G Clarke WebSphere Messaging Clients IBM Hursley MQSeries List <[email protected]> wrote on 14/07/2005 13:46:30: > T.Rob, David, > > I do not know, who is right. I would expect a behaviour as David describes, > but I would be not very surprised, whe T.Rob is right. I am in doubt, > because MQ tries to find a way to the target QMgr. E. g. when you define a > remote queue without having a local tranmission queue and "normal" sender / > receiver channel, but MQ "knows" a cluster channel to the target QMgr, the > message will be send using the cluster channel, although the remote queue as > well as the target queue are NOT in any cluster. > > Maybe we need a "real" expert (like Paul Clarke ;-) ) to clarify the > situation. > > Regards > Hubert > > > > -----Ursprüngliche Nachricht----- > > Von: MQSeries List [SMTP:[EMAIL PROTECTED] im Auftrag > > von David C. Partridge > > Gesendet am: Donnerstag, 14. Juli 2005 14:32 > > An: [email protected] > > Betreff: Re: MQ Clustering question > > > > T. Rob said: > > > > >When you have overlapping clusters and two channels leading to the same > > instance of > > >a cluster queue, both channels are eligible to send the message. > > >This is true even if the channels are in different clusters and the > > cluster > > queue > > >exists in only one of them. > > > > No that shouldn't happen IMO - if a cluster queue is defined in only one > > cluster, then only the cluster channels for THAT cluster should be > > eligible > > to send messages to that queue. The APAR I was referring to in my > > earlier > > post related to the problem that it WAS behaving as you describe. > > > > I'm still trying to find out the relevant APAR number and platforms. > > > > David > > -----Original Message----- > > From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf > > Of > > Wyatt, T Rob > > Sent: 14 July 2005 13:22 > > To: [email protected] > > Subject: Re: MQ Clustering question > > > > Rao, > > > > Remember that clusters are really just namespaces. When you have > > overlapping clusters and two channels leading to the same instance of a > > cluster queue, both channels are eligible to send the message. This is > > true > > even if the channels are in different clusters and the cluster queue > > exists > > in only one of them. You can set NETPRTY on the channels so one is > > favored > > over the other but that does not provide the QOS you want. > > > > I believe, and someone please correct me if I am wrong, that your only > > option here is to create a workload exit or fall back to classic channels. > > If you use classic channels, they can coexist with the cluster, you just > > need to point the channels at QMgr aliases that are not known to the > > cluster. So if you want to send to cluster QMgr QM1 then you would define > > a > > QMgr alias on it like... > > > > DEF QR(QM1.QOS) RQMNAME('QM') RNAME(' ') CLUSTER(' ') CLUSNL(' ') > > > > On the sending side you need an XMitQ and channel to QM1.QOS. As long as > > QM1.QOS is not known to the cluster, you can direct messages down this > > channel. You can have as many of these as you need such that normal > > messages use the cluster channels and batch or large messages use one of > > the > > QOS channels. > > > > Hope that helps so you don't have to tear down you cluster! > > > > -- T.Rob > > > > -----Original Message----- > > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf > > Of > > Rao Adiraju > > Sent: Thursday, July 14, 2005 4:31 AM > > To: [email protected] > > Subject: MQ Clustering question > > > > > > Fellas > > > > We have connected two queue managers - say QM1 and QM2 by putting them in > > a > > cluster. We have a requirement to support Quality of Service (Qos) - in > > the > > sense we need three separate channels between them to support online, > > batch, > > bulk data transfer. > > > > So the next suggestion came is - to define three clusters between these > > same > > two queue managers with each cluster having its own Cluster sender / > > Receiver channels to support this QOS. > > > > Here comes my question - in Cluster SENDER channel definitions I didn't > > see > > any option of specifying transmission queue name and what I have seen is > > all > > three sender channels are polling on SYSEM.CLUSTER.TRANSMIT.QUEUE. So even > > going to this length, am I stuck up with Single Transmission queue ??? > > > > 1) Is there a way to tie up each Cluster Sender channel to a specified > > transmission queue or not. > > > > 2) Is there any other way of implementing clusters so that the three QoS > > can > > be supported. > > > > My personal preference is to get rid of this clustering and use DQM - with > > three different transmission queues, three Sender channels. > > > > Thanks in advance > > > > Cheers > > > > Rao > > > > ***************************************************** > > * Rao ADIRAJU * > > * Distributed Systems Consultants Pty. Ltd. * > > * GPO Box 1177, Canberra - ACT - 2601 * > > * AUSTRALIA * > > * Email: [EMAIL PROTECTED] * > > * [EMAIL PROTECTED] * > > * > > * Tel:+61-419-022-126 Fax:+61-262-900-200 * > > ***************************************************** > > > > 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 > > > > 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 > > > > 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 > > 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 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
