| Author |
Message
|
| JYama |
 Posted: Wed Sep 19, 2007 5:34 am Post subject: MQInput Node with a cluster queue |
 |
|
Master
Joined: 27 Mar 2002
Posts: 281
|
Hi, all,
I'm facing a strange situation.
If there's anybody who has experience, please help.
Now I'm using WMBv6.0 and WMQv6.0.
They are running on the same AIX box.
Now I have two brokers and the same message flow is deployed.
The point is that MQ Input node of the message flow is looking up a cluster queue.
Thus incoming messages are "round-robined" but if message flow is running it's not. One curious thing is that if the flow is NOT runnning, incoming messages are successfully "round-robined".
I have no idea on this.
How can I cope with the situation?
Many thanks in advance, |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Sep 19, 2007 6:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Like all queue reading programs, the MQInput node can only read from the local copy of a cluster queue. So it should only receive the messages directed at it.
Don't forget that the round robin behaviour can be overriden by things like bind on open or specific replies.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JYama |
| Posted: Wed Sep 19, 2007 7:16 am Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
Thank you very much for your post, Vitor.
| Quote: |
| Don't forget that the round robin behaviour can be overriden by things like bind on open or specific replies. |
You mean, bind mode of the MQ input node? I couldn't find any effective properties related to binding in the MQ input node.
I thought message "senders" were surely responsible for the binding mode and the message flows were message "receiver" in this case. So I guess "binding mode" is OK.
One "tricky" thing is that the senders are JMS applications running on WASv6 thus (MQ)"binding mode" is not available for these JMS appls.
My question is why round-robin route is fixed when the message flow(s) is running.
DEFBIND of the cluster queue is "NOTFIXED", BTW.
What's going on?
 |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 19, 2007 7:28 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| JYama wrote: |
| I thought message "senders" were surely responsible for the binding mode and the message flows were message "receiver" in this case. So I guess "binding mode" is OK. |
No, you're quite right. I was making a general point that the cluster behaviour can be overriden by various things.
| JYama wrote: |
One "tricky" thing is that the senders are JMS applications running on WASv6 thus (MQ)"binding mode" is not available for these JMS appls.
|
I'll take your word for that.
| JYama wrote: |
My question is why round-robin route is fixed when the message flow(s) is running.
|
I don't see a mechanism myself. How would the workload algorthm know what applications had what queues open? 
Unless there's something affecting the priorities (remember v6 is not fixated on round robin like the previous versions).
| JYama wrote: |
DEFBIND of the cluster queue is "NOTFIXED", BTW.
|
It's only a default. Doesn't mean it's in use. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Sep 19, 2007 7:32 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
BIND_ON_OPEN has nothing to do with "bindings" connections.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JYama |
| Posted: Wed Sep 19, 2007 7:55 am Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
The architecture is quite compicated so let me explain.
JMS appl --(MQ client)--> QMgr1.aliasQ
-----------------------------------------------> QMgr2.clusterQ (to the msgflow)
-----------------------------------------------> QMgr3.clusterQ (to the msgflow)
(All of them are running in the same box.)
One broker is runnning on QMgr2 and the flow is looking up clusterQ and another broker is runnning on QMgr3 and also looking up clusterQ.
The JMS application has a MQ 'client connection' to QMgr1 and put messages on aliasQ pointing "clusterQ".
When the two msgflows are not running, messages are equally sent to QMgr2 and QMgr3.
For example, when the JMS appl send four messages like 1,2,3,4, then 1,3 are in QMgr2.clusterQ and 2, 4 are in QMgr3.clusterQ.
However, if the flows are running, these messages are only sent to QMgr2.clusterQ. Why? Why? Why?
How can the flow influence the behavior of MQ clustering?
What's going on?? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 19, 2007 8:40 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You are right to be confused. Whether a queue is open for input or not should have nothing to do with how the cluster distributes messages.
There must be some other critical detail you are not sharing or aware of.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Wed Sep 19, 2007 8:49 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi JYama,
Is it possible that your flow on QMgr2 is eating up the incoming messages so quickly that, the QMs do not have to apply load balancing and put the next message on QMgr3 ?  Just trying to make some sense of the situation 
This could be tested if you could pause the flow on QMgr2 by perhaps putting a pseudo MQGet wait, while the message 2, 3 and 4 are sent to QMgr3....
Regards. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 19, 2007 9:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| elvis_gn wrote: |
Hi JYama,
Is it possible that your flow on QMgr2 is eating up the incoming messages so quickly that, the QMs do not have to apply load balancing and put the next message on QMgr3 ? Just trying to make some sense of the situation |
That's not how MQ clustering works.
Unless there is a custom cluster workload algoritim in place that is checking the q depth on every instance of a cluster q before every message it moves, which would kill performance so I doubt someone built that.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JYama |
| Posted: Wed Sep 19, 2007 5:37 pm Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
| elvis_gn wrote: |
Hi JYama,
Is it possible that your flow on QMgr2 is eating up the incoming messages so quickly that, the QMs do not have to apply load balancing and put the next message on QMgr3 ? Just trying to make some sense of the situation
|
I stopped the message flow on QMgr2, then sent messages like 1,2,3,4.
1 was sent to QMgr2 and 2,3,4 to QMgr3. ? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 19, 2007 6:09 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Be aware that one of the things the cluster workload algorithim looks at when determining where to send messages is the sequence # on the channels. If one channel's seq # is rising faster than the other, the algorithim will assume that QM is busier and will send more work to the other QM.
So lets say you have ClusterQueue on QM2 and QM3 for Application Alpha. But QM1 is sending lots more messages for Application Beta to QM2 (maybe App Beta only has a q on QM2 and QM4 so nothing for App Beta goes to QM3).
Application Alpha's messages will mostly go to QM3 in this case because QM2 looks busier to the algorithim.
IF this is your problem I would think it happens regardless of whether your flows are running or not. Like I said unless you got a custom cluster workload exit installed doing something as whacky as checking input q depths and IPROCS I don't see how your flow could be affecting the round robining.
Or whoever wrote the JMSapplication is messing with you and they are hard coding the destination QM some of the time telling the cluster to put the messages to one QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JYama |
| Posted: Wed Sep 19, 2007 10:02 pm Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
| PeterPotkay wrote: |
Be aware that one of the things the cluster workload algorithim looks at when determining where to send messages is the sequence # on the channels. If one channel's seq # is rising faster than the other, the algorithim will assume that QM is busier and will send more work to the other QM.
|
Is it the round-robin algorithm of MQ?
Now I'm confusing the difference between "round-robin" and workload algorithm
I was thinking that round-robin was simpler like messages were always balanced like 1,2,1,2,1,2,,, without caring who's busier.
Was it my misunderstanding???
I know now WMBv6 supports weighted round-robin but I'm not using it, BTW. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 19, 2007 10:52 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| JYama wrote: |
I was thinking that round-robin was simpler like messages were always balanced like 1,2,1,2,1,2,,, without caring who's busier.
Was it my misunderstanding???
|
From the Clusters manual:
| Quote: |
Note that the distribution of user messages is not always exact, because administration and maintenance of the cluster causes messages to flow down channels. This can result in an apparent uneven distribution of user messages Workload balancing which can take some time to stabilize. Because of this, no reliance should be made as to the exact distribution of messages during workload balancing. |
The bold is mine.
My reading of this is that while the workload algorithm does use round robin as a basis, it's only a basis and various factors can affect it.
Though I must say I agree with Peter and it sounds like someone's got bind on open specified! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JYama |
| Posted: Wed Sep 19, 2007 11:03 pm Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
| Quote: |
| Though I must say I agree with Peter and it sounds like someone's got bind on open specified! |
Well, I'll check applications' logic connecting to the broker QMgrs.
Yes, there are many factors that can affect the behavior.
Thank you very much for usefull information, all! |
|
| Back to top |
|
|
| JYama |
| Posted: Thu Sep 20, 2007 12:09 am Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
I learned that the workload balance is based on MQWDR.DestSeqNumber that the channel owning the lowest value will be chosen.
How is DestSeqNumber available?
I can't find a way to configure or monitor this parameter.
Any ideas? |
|
| Back to top |
|
|
|
|
