Peter, it is quite "normal", that cluster changes take a while until they are known by the cluster. So it also would be quite normal, that it takes a while until the load-balancing mechanism switches back to the higher prioritized queue. But I would not expect, that in the meantime messages are sent to BOTH QMgrs!
Regards Hubert > -----Ursprüngliche Nachricht----- > Von: MQSeries List <[email protected]> > Gesendet: 24.05.07 16:28:22 > An: [email protected] > Betreff: Re: Strange behavior for load balancing with MQ 6.0 > > LMD responded that this "bad" behavior only exists for a couple of seconds. > This could be the time it takes the channel to go through all its various > phases between INACTIVE and finally RUNNING, during which time the higher > priority QM is considered unavailable. WE know that the QM is up, but I see > the cluster workload algorithm's point. How's it supposed to know that a > channel that is BINDING or STARTING is going to be in that state for half a > second, or half a day? I guess they had no choice but to code it this way. If > so, the doc needs to be beefed up to make this point very clear. And/or there > should be CLWLPRTY INTERVAL parm added, so MQ Admins can control this a > little bit. > > > I asked IBM on the Hursley MQ Blog site (very cool check it out: > http://hursleyonwmq.wordpress.com/ ) in a post asking for article ideas for > an article on how the cluster workload algorithm does its thing at MQ 6.0, > and to address this scenario. Maybe we'll see something there, or hopefully > one of them will confirm or correct our assumptions here. > > > Peter > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Hubert Kleinmanns > Sent: Thursday, May 24, 2007 2:17 AM > To: [email protected] > Subject: Re: Strange behavior for load balancing with MQ 6.0 > > Peter, > > you are right, channel priority is checked AFTER the channel status, but > INACTIVE and RUNNING channels are selected in the same step. So if the > channel with higher priority is in status INACTIVE, this one should be > selected. Only if this channel is in a state other than INACTIVE or RUNNING > (and channel with lower priority is in status INACTIVE or RUNNING) - the > channel with the lower priority should be selected. > > This means with > > DEFBIND(NOTFIXED) - The higher priority channel would be used as soon as > it becomes INACTIVE or RUNNING. > > DEFBIND(OPEN) - The lower priority channel would be used until the next > MQCLOSE. > > So I would expect, that the message will be sent either to the higher or to > the lower prioritized queue - but no load-balancing. > > But, could it be, that messages already have been put to the > SYSTEM.CLUSTER.TRANSMIT.QUEUE when the channel to the higher prioritized > channel becomes available? Then I would expect, that following message would > have been sent to the higher prioritized queue. > > To me it looks like a bug, not a feature. > > Regards > Hubert > > > -----Ursprüngliche Nachricht----- > > Von: MQSeries List <[email protected]> > > Gesendet: 23.05.07 18:50:46 > > An: [email protected] > > Betreff: Re: Strange behavior for load balancing with MQ 6.0 > > > > > > ****************************************************** > > LMD wrote: > > On normal circonstances, when I put a message from GUEP to GUE_SAG queue, > > the message is delivered on GUE_SAG queue on SAGP. > > After a restart (endmqmq + strmqm) of GUEP, if I put ONE message from GUEP > > to GUE_SAG, the message is delivered on SAGP queue. > > > > After a restart (endmqmq + strmqm) of GUEP, if I put MORE THAN ONE message > > from GUEP to GUE_SAG (for example using the "Put Message" option from MO71 > > and "Message count = 5") on a short period of time (say 2 seconds), load > > balancing occurs between SAGP et SAGS queues. > > Same if I use amqsput with a hight rate of inputs (so this is not a MO71 > > related behaviour). > > This is true only for the first "batch" of messages, other puts send all > > mssages to SAGP queue. > > ****************************************************** > > > > > > So for how long does the unexpected / unwanted load balancing occur? > > > > I'm with you on this one, in that it doesn't work like we think it should. > > But check this quote out a few sentences later under CLWLPRTY: > > ****************************************************** > > Quote: > > WebSphere MQ obtains the priority of queue managers after checking channel > > status. This means that only accessible queue managers are available for > > selection, and it allows WebSphere MQ to prioritize, where multiple > > destinations are available. > > ****************************************************** > > > > After checking Channel Status? Well, there's your problem. And if true, I > > think it makes CLWLPRTY a little less useful than you would first imagine. > > > > I guess it boils down to is any channel status other than Running or > > Inactive going to be treated as an un-"accessible" QM, in which case it is > > ignored and CLWLPRTY takes a back seat to a starting channel? > > > > Ian? Morag? > > > > > > -Peter > > > > > > -----Original Message----- > > From: MQSeries List [mailto:[EMAIL PROTECTED] On > > Behalf Of LM Demey (MQ) > > Sent: Monday, May 21, 2007 1:15 PM > > To: [email protected] > > Subject: Strange behavior for load balancing with MQ 6.0 > > > > Hi all, > > > > I'm facing an interesting situation about load balancing with > > clustered queues on MQ V6.0 > > > > I have a network of 6 Queue Managers, 3 on a Primary site (suffixed "P"), 3 > > on a Secondary site (suffixed "S") S is supposed to be the backup of the > > corresponding P Queue Managers in case of failure. > > On the P side, I have the following QM: > > - POSP --> Full repository > > - GUEP --> The QM where source application reside > > - SAGP --> The QM where target application reside On the S side, I have > > the 3 same QM, ending with S instead of P. > > > > GUEx and SAGx have explicit sender channels to POSP and POSS. > > > > All the six QM belongs to the same MQ Cluster. > > On SAGP and SAGS, I have a cluster queue named GUE_SAG. > > On SAGP, the channel TO.SAGP have a cluster priority of 6. > > On SAGS, the channel TO.SAGS have a cluster priority of 0. > > All other parameters are default. > > > > On normal circonstances, when I put a message from GUEP to GUE_SAG queue, > > the message is delivered on GUE_SAG queue on SAGP. > > After a restart (endmqmq + strmqm) of GUEP, if I put ONE message from GUEP > > to GUE_SAG, the message is delivered on SAGP queue. > > > > After a restart (endmqmq + strmqm) of GUEP, if I put MORE THAN ONE message > > from GUEP to GUE_SAG (for example using the "Put Message" option from MO71 > > and "Message count = 5") on a short period of time (say 2 seconds), load > > balancing occurs between SAGP et SAGS queues. > > Same if I use amqsput with a hight rate of inputs (so this is not a MO71 > > related behaviour). > > This is true only for the first "batch" of messages, other puts send all > > mssages to SAGP queue. > > > > This is not the behavior I expect for load balancing in this transient > > situation .... > > > > Do I have miss something in parameters ? > > Is this a bug, a feature ? > > > > I was able to reproduce this: > > - on Aix, with MQ 6.0.1.0 > > - on Linux, with MQ 6.0.1.0 and 6.0.2.0 > > - on WinXP, with MQ 6.0.2.0 and 6.0.2.1 > > > > Any help will be greatly appreciated. > > > > PS : I can provide MQSC définitions for this cluster, who actually run on > > my laptop. > > > > -- > > Luc-Michel Demey - Freelance WMQ Expert > > http://www.demey-consulting.fr/ - lmd at demey-consulting dot fr > > > > 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 > > 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 > > 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 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 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
