Paul, I do not think, you will find any overhead, because the cluster mechanism uses counters, to define the channel, which transports the next message. This counter is increased, whenever a message is sent. MQ does not resolve the queue on each MQPUT. In fact, your application always puts a message to the local SYSTEM.CLUSTER.TRANSMIT.QUEUE.
I guess, with DEFBIND(NOTFIXED) and at least two instances of a cluster queue, you will speed up the transport. This is, because more channel agents read the SYSTEM.CLUSTER.TRANSMIT.QUEUE in parallel, which should increase the number of messages per second (see IBMs performance documents for the effect of parallel running applications). Even if you have only one instance of the queue, but two cluster channel defined, I would expect a higher performance, because MQ clustering balances over the channel - that means paths to a queue - not the queues itself. Regards Hubert > -----Ursprüngliche Nachricht----- > Von: MQSeries List [SMTP:[EMAIL PROTECTED] im Auftrag > von Paul V DAngelo > Gesendet am: Mittwoch, 6. Juli 2005 22:39 > An: [email protected] > Betreff: Re: AW: Workload exit from Broker > > On Wed, 6 Jul 2005 18:40:48 +0200 Hubert Kleinmanns wrote > > > > when the cluster queues are defined with the attribute > > DEFBIND(OPEN), I > > expect the behaviour you describe. Try to define the cluster queues > > with the > > attribute DEFBIND(NOTFIXED), and the cluster mechanism redefines the > > (real) > > target queue on each MQPUT. > > > > Remember, all instances of a cluster queue have to be defined in the > > same > > way. > > > > > Hubert, > When the queue is defined with DEFBIND(NOTFIXED) within a cluster, > what overhead will be added if any to the quque manage or the broker ? > > pd > ================================================================= > ================================================================= > > > Betreff: Workload exit from Broker > > > > > > We are using version 5.0.4 of WBIMB, accessing a clustered 5.3 > > queue > > > manager. We have flows that put messages onto a clustered queue > > that is > > > hosted by several other servers. However, since the workload exit > > is > > > driven at MQOPEN time, and since the broker doesn't issue a > > MQCLOSE after > > > doing a put, we really aren't getting the benefits of the workload > > exit to > > > round robin these messages to all of the other servers, but > > instead are > > > really basically fixed to one server. Obviously if components are > > stopped > > > and started you might drive to a different server, but in general, > > once > > > the broker has attached himself to a clustered queue instance, it > > stays > > > with that instance. > > > > > > My question is, how are other folks handling the load balancing > > issues > > > when coming out of the broker? Do you just live with the fact > > that you're > > > linked to one, or have you implemented any solutions? > > > > > > We've raised a requirement on this, but wondered if there were any > > > solutions out there. > > > > > > Thanks. > > > > > > Tim > > > _____ > > > > > > This message and any attachments are intended only for the use of > > the > > > addressee and may contain information that is privileged and > > confidential. > > > If the reader of the message is not the intended recipient or an > > > authorized representative of the intended recipient, you are > > hereby > > > notified that any dissemination of this communication is strictly > > > prohibited. If you have received this communication in error, > > notify the > > > sender immediately by return email and delete the message and any > > > attachments from your system. > > > 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
