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
