Christopher, I thought, I answered your mail already, but something went wrong, so I try it again.
What I mean with "breaking a fly on the wheel" is: - Message broker licenses costs nearly 10 times or more of what a MQ license costs. - For MQ admins you need addional tools, to configure the broker flow. - MQ admins need to build up broker know-how in addition to MQ know-how. - Message broker need (additionally) CPU time, use memory and disk space. So if you have already a message broker, it could make sense, to use it as a routing tool, but when you have to set-up a new message broker for these purposes, you are breaking a fly on the wheel. It depends on the point of view, if MQ configuration is easier than Flow changes. MQ admins are very fast, to change a single Q definition. Broker experts - I think - are faster, to change and deploy a flow. But the easiest way in a MQ cluster environment is, to send messages in one cluster directly - not over a gateway QMgr. QSGs and shared queues are better then cluster queues ... hmmm. This also depends on ... E. g. if you have MQ version 6 and persistent messages greater then 63 kB shared queues are definitely slower than local (clustered) queues! You told, messages take .004 seconds over conventional channel and 0.014 seconds over cluster channel. I think this will also depend on the specific environment. But I am missing one number: How long is the time, the routing flow in the message broker needs, to read a message, execute the routing calculation, and put it again? My experiences with MQ and message broker are, that MQ is generally much faster than any flows - but I guess, this also depends on ... ;-(. I am still in doubt, that a message broker as a message router will give you any performance advantages compared with a native MQ solution. When I would get performance issues in a native MQ environment, I would prefer, to optimize the MQ transport mechanisms. Regards Hubert > Delivered-To: [email protected] > Content-Type: text/plain; charset=iso-8859-1 > Message-ID: <[EMAIL PROTECTED]> > Date: Tue, 28 Nov 2006 14:52:01 -0800 > Reply-To: MQSeries List <[email protected]> > Sender: MQSeries List <[email protected]> > From: Christopher Warneke <[EMAIL PROTECTED]> > Subject: Re: multi-hop within a cluster > In-Reply-To: <[EMAIL PROTECTED]> > Reasons why I disagree: > > 1. For all of the simplification that clustering > brings, there is a loss of performance. We see times > of .004 seconds for unclustered (sdr/rcvr pair) > message transmission avg. verses .014 seconds for > cluster message transmission avg. In this shop, 10ms > here, 10ms there, means not having transactions > complete in less than a second. We need subsecond > response times. > > 2. It's a lot easier to change 1 routing rule in a > control table, than to change n number of mq object > definitions. Sure, in some little test environment > you can go and change things as you want - on a > production system, the change mangement work to > redefine the mq environment will make you wish you > only had to change 1 routing rule. > > 3. QSGs and Shared Channel solutions are better than > clustering - if you have z/OS. If not, maybe > performance is not such an issue and you can cluster > the thing to death. Most of the MQ performance issues > that we see, result from designs that work. Messages > get where they are supposed to go. Just not that > efficiently - and then things begin to fail under > heavy load. > > 4. What exactly does "breaking a fly on the wheel" > mean? Do you mean that it is overkill? There is a > point in scale where brokering is the easiest > approach, and your clustering solution becomes the fly > in vaseline. Think about support for this, as if you > were not the person supporting it. Maybe the 'next > guy' wants to do it the easy way, and have the > application people be responsible for routing changes. > > > So there... > > > --- Hubert Kleinmanns <[EMAIL PROTECTED]> wrote: > > > I think, using a message broker to route messages is > > like breaking a fly on the wheel ... > > > > MQ clustering is designed for simplifying > > administration tasks. Now you need not to define any > > channel definitions or remote Q definitions > > manually. The cluster algorithm propagates the > > neccessary definitions to the cluster members, but > > the Qs and channels are going the direct way. > > > > But, you could define alias queues on a gateway > > system, which point on local queues on the target > > systems. In this case alias queues and local queues > > must have different names. I did not test it, but > > this should work. > > > > I would NOT use the mechanism I described above, > > because it is contrary to the cluster concepts. > > Instead I would use overlapping clusters as follows: > > > > 1. Put the sending QMgrs and the gateway QMgrs into > > one cluster (e. G. CL1). > > > > 2. Put the receiving QMgrs and the gateway QMgrs > > into a second cluster (e. G. CL2). > > > > 3. Define alias Qs on the gateway QMgrs in CL1, > > which point to local Qs in cluster CL2. > > > > 4. On the sending QMgrs put the messages to the > > alias Qs in cluster CL1 on the gateway QMgrs. > > > > 5. The gateway QMgrs now resolve to the local Qs in > > cluster CL2. > > > > 6. The sending QMgrs do not see the local Qs in > > cluster CL2, so the names of the alias Qs on the > > gateways and the local Qs on the receiving QMgrs may > > have the same name. > > > > I tested point 6 and it worked, but maybe when you > > have to gateways, they could route the messages to > > the other gateway (and back). In WebSphere MQ > > version 6 this may be prevented by using the > > CLWLRANK attribute. > > > > Regards > > Hubert > > > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: MQSeries List > > <[email protected]> > > > Gesendet: 27.11.06 23:46:48 > > > An: [email protected] > > > Betreff: Re: multi-hop within a cluster > > > > > > > ...or, you could employ/author a message broker > > with > > > clientconns connecting to whatever qmgrs are > > involved, > > > give it http connections though it's own tomcat > > server > > > - call it your Enterprise Service Buss. > > > It depends on how complex you want your plumbing > > to > > > be. > > > Do you want to change a routing entry in a control > > > table, or restructure the mq environment, when > > routing > > > changes are made? > > > > > > > > > --- Neil Casey <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > Hi all, > > > > > > > > my take on this (for what it's worth). > > > > > > > > In MQ there is an assumption that all queue > > managers > > > > within a cluster are > > > > able to communicate directly. If you attempt to > > put > > > > a message to a cluster > > > > queue, the FR will notify your local QM of the > > > > locations of that queue, > > > > and of the channel definitions required to get > > to > > > > those locations. These > > > > definitions are based on the cluster receiver > > > > channels to the target queue > > > > managers, and so direct connection capability is > > > > needed. That is, in order > > > > for messages to be sent to any possible > > destination > > > > within the cluster, > > > > the cluster must be fully inter-connected. > > > > > > > > In an environment where this is not the case, as > > in > > > > this example, you > > > > should not define one cluster, but rather 2 or > > more. > > > > Each cluster you > > > > define should be fully connected, and there > > should > > > > be one or more queue > > > > managers in both clusters. You can then use > > standard > > > > cluster gateway > > > > techniques to forward messages between the > > clusters. > > > > > > > > There is no simple way to implement forwarding > > of > > > > messages via > > > > intermediate queue managers in a single cluster, > > > > although you might be > > > > able to do it by... > > > > > > > > QM1, QM2 and QM3 are members of CLUS1. They all > > have > > > > connectivity to the > > > > full repositories, and QM2 has 2 way > > connectivity to > > > > QM1 and QM3. QM1 and > > > > QM3 cannot be connected directly, and are > > partial > > > > repositories. > > > > Set up the target queue (TQ1) on a queue manager > > > > (QM1), but NOT visible in > > > > the cluster. > > > > Set up a QRemote on a fully connected queue > > manager > > > > (QM2), with QUEUE(TQ1) > > > > RQMNAME(QM1) XMITQ(' ') RNAME(TQ1) > > CLUSTER(CLUS1) > > > > DEFBIND(NOTFIXED) > > > > Put to TQ1 from your isolated queue manager > > (QM3). > > > > It should resolve to > > > > the queue on TQ1 and send the message there. > > When it > > > > gets there, name > > > > resolution should allow the message to be > > forwarded > > > > to the correct queue > > > > on QM1. > > > > > > > > I haven't tested this design to ensure that it > > > > works, but I think it > > > > would. It does not support load balancing across > > > > several possible > > > > destinations. > > > > > > > > I would implement this with 2 clusters, not with > > a > > > > single cluster which is > > > > somewhat broken. The 2 cluster design does > > support > > > > load balancing. > > > > > > > > The 2 cluster design would have QM1 and QM2 in > > > > CLUS1, and QM2 and QM3 in > > > > CLUS2. > > > > > > > > The queue definitions to enable access from QM3 > > to > > > > QM1 via the gateway > > > > would be... > > > > on QM1 define QL(TQ1) cluster(CLUS1) > > > > defbind(notfixed) > > > > on QM2 define QA(TQ1.VIA.CLUS2) targq(TQ1) > > > > cluster(CLUS2) > > > > defbind(notfixed) > > > > on QM3 define QA(TQ1) targq(TQ1.VIA.CLUS2) > > > > defbind(notfixed) cluster(' ') > > > > > > > > QM3 can now put to TQ1 and the message will > > traverse > > > > the network via QM2 > > > > to QM1. > > > > > > > > The reason for changing the name of the queue on > > the > > > > gateway queue manager > > > > is so that you can have more than one gateway. > > We > > > > can enhance the design > > > > above by adding QM4, which is in CLUS1 and > > CLUS2. It > > > > has QA(TQ1.VIA.CLUS2) > > > > with exactly the same definition as on QM2. This > > > > cluster gateway design > > > > will now continue to operate, even if one of QM2 > > or > > > > QM4 are unavailable, > > > === message truncated === > > 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 > > 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
