|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
Changing default clustering behavior |
« View previous topic :: View next topic » |
Author |
Message
|
yalmasri |
Posted: Tue Apr 20, 2010 7:20 am Post subject: Changing default clustering behavior |
|
|
Centurion
Joined: 18 Jun 2008 Posts: 110
|
In MQ V6, if we have a cluster of 3 machines A, B and C, with clustered queue Q1 defined on machines A and B, then1. An application on A will always send to the queue on A and never to that on B, which means we effectively don't have clustering.
2. An application on C will send 50% of the messages to A and 50% to B. Is there a way to change this default in both cases? I mean I want for example to send 50% to A and 50% to B in the first case, and 30% to A and 70% to B in the second case. Is that possible? What about in MQ V7? |
|
Back to top |
|
 |
Vitor |
Posted: Tue Apr 20, 2010 7:32 am Post subject: Re: Changing default clustering behavior |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
yalmasri wrote: |
1. An application on A will always send to the queue on A and never to that on B, which means we effectively don't have clustering. |
Don't set USEQ(LOCAL)
yalmasri wrote: |
2. An application on C will send 50% of the messages to A and 50% to B. |
Change the queue weighting in the cluster, the channel weighting or both.
yalmasri wrote: |
What about in MQ V7? |
Possible in v6 & v7, all documented in the cluster manual _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Apr 20, 2010 9:15 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
moving to clustering... _________________ MQ & Broker admin |
|
Back to top |
|
 |
yalmasri |
Posted: Sun Apr 25, 2010 7:14 am Post subject: |
|
|
Centurion
Joined: 18 Jun 2008 Posts: 110
|
Let's take first point for now.
I tried a couple of combinations and got very strange results (the sender application is on A):1. On A, CLWLUSEQ attribute is Local for QM & Any for Q, while on B, it's Local for QM and Any for Q --> all message go to B
2. On A, CLWLUSEQ attribute is Local for QM & Any for Q, while on B, it's Local for QM and QMGR for Q --> all message go to B
3. On A, CLWLUSEQ attribute is Local for QM & QMGR for Q, while on B, it's Local for QM and Any for Q --> all message go to A
4. On A, CLWLUSEQ attribute is Any for QM & Any for Q, while on B, it's Any for QM and Any for Q --> very few messages go to B and the rest ... I just can't see them anywhere, not even in the dead letter queue!
5. On A, CLWLUSEQ attribute is Any for QM & QMGR for Q, while on B, it's Any for QM and QMGR for Q --> nothing at all was sent to either A or B! Is there any magical configuration I'm missing that's turning everything here into mess? |
|
Back to top |
|
 |
bruce2359 |
Posted: Sun Apr 25, 2010 8:43 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
1. An application on A will always send to the queue on A and never to that on B, which means we effectively don't have clustering. |
Not precisely true that you don't have clustering.
The folks at the WMQ factory are aware that nn app on the same qmgr as an instance of the cluster destination queue will get better response (throughput) than a if a msg must traverse a network. This is why the default behavior is to find the local instance of the queue - if one exists.
Quote: |
An application on C will send 50% of the messages to A and 50% to B. |
Yes. The CLWLUSEQ setting allows for the local instance of the queue to be used in the round-robin distribution of messages to other instances of the cluster queue.
Although this will likely give you even distribution of messages across all instances of the cluster destination queue, why would you want to?
Needlessly routing messages across a network to achieve even distribution of request messages incurs needless latency for requesting/replying apps that exist on the same platform.
Can you provide some more information about what you/your developers are trying to accomplish? _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun Apr 25, 2010 9:14 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
yalmasri wrote: |
Let's take first point for now.
I tried a couple of combinations and got very strange results (the sender application is on A):1. On A, CLWLUSEQ attribute is Local for QM & Any for Q, while on B, it's Local for QM and Any for Q --> all message go to B
2. On A, CLWLUSEQ attribute is Local for QM & Any for Q, while on B, it's Local for QM and QMGR for Q --> all message go to B
3. On A, CLWLUSEQ attribute is Local for QM & QMGR for Q, while on B, it's Local for QM and Any for Q --> all message go to A
4. On A, CLWLUSEQ attribute is Any for QM & Any for Q, while on B, it's Any for QM and Any for Q --> very few messages go to B and the rest ... I just can't see them anywhere, not even in the dead letter queue!
5. On A, CLWLUSEQ attribute is Any for QM & QMGR for Q, while on B, it's Any for QM and QMGR for Q --> nothing at all was sent to either A or B! Is there any magical configuration I'm missing that's turning everything here into mess? |
You did not specify 2 important factors: persistence of messages and reliability of network....
So your results have no meaning at all  _________________ MQ & Broker admin |
|
Back to top |
|
 |
yalmasri |
Posted: Sun Apr 25, 2010 10:59 pm Post subject: |
|
|
Centurion
Joined: 18 Jun 2008 Posts: 110
|
Quote: |
Not precisely true that you don't have clustering. |
You're right, a more precise word would be "load balancing"
Quote: |
Needlessly routing messages across a network to achieve even distribution of request messages incurs needless latency for requesting/replying apps that exist on the same platform. |
For some reason that's out of my hands, two instances of a client application are located on two machines, and they are sending messages to another 6-instance clustered application, so if one of client application instances hijacked the local instance and kept sending to, it will kneel it down. So what I can do is distributing the load while allowing the local one to take good share
Quote: |
You did not specify 2 important factors: persistence of messages and reliability of network.... |
Can you please explain how this is going to affect my clustering options?
Quote: |
So your results have no meaning at all |
I guess we have to ignore these results all together because I was doing the changes without restarting my applications, which caused this unexplained behavior.
Quote: |
Change the queue weighting in the cluster, the channel weighting or both. |
Vitor, I could only see weighting on channel level but couldn't find anything on the queue level (which what I'm actually looking for!). I'm sure I read the cluster manual carefully. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Apr 26, 2010 3:09 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
yalmasri wrote: |
Quote: |
You did not specify 2 important factors: persistence of messages and reliability of network.... |
Can you please explain how this is going to affect my clustering options?
Quote: |
So your results have no meaning at all |
I guess we have to ignore these results all together because I was doing the changes without restarting my applications, which caused this unexplained behavior. |
If there is a problem with one of the channels it is very likely that it will no longer participate in load distribution. Also make sure that the queues are set to default bindings NOT FIXED. Otherwise all messages from the app will go to a single destination. If your messages are not persistent they may get discarded inside the channel as defined in the manuals.
yalmasri wrote: |
Quote: |
Change the queue weighting in the cluster, the channel weighting or both. |
Vitor, I could only see weighting on channel level but couldn't find anything on the queue level (which what I'm actually looking for!). I'm sure I read the cluster manual carefully. |
Did you look at this link?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
yalmasri |
Posted: Mon Apr 26, 2010 6:21 am Post subject: |
|
|
Centurion
Joined: 18 Jun 2008 Posts: 110
|
fjb_saper wrote: |
If there is a problem with one of the channels it is very likely that it will no longer participate in load distribution. Also make sure that the queues are set to default bindings NOT FIXED. Otherwise all messages from the app will go to a single destination. If your messages are not persistent they may get discarded inside the channel as defined in the manuals. |
Default binding type is NOT FIXED and queue is persistent.
Yes, nothing one weight, only priority, rank and use queue.
I think I need to be a little bit more focused here. For that I redid my tests and made sure I have consistent and reproducible results (I made sure also I restarted my applications this time). The first case is configured like this.
On machine A CLWLUSEQ attribute is: "Local" for queue manager and "Any" for queue
On machine B CLWLUSEQ attribute is: "Local" for queue manager and "Any" for queue
A ran an application on A for this configuration but messages were sent all the time to B, and vice-versa, when I ran it on B all messages went to A.
Now can anybody tell me what's going on? |
|
Back to top |
|
 |
Vitor |
Posted: Mon Apr 26, 2010 6:27 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
yalmasri wrote: |
So what I can do is distributing the load while allowing the local one to take good share |
And if the application chooses to it can still hijack the local instance.
yalmasri wrote: |
I'm sure I read the cluster manual carefully. |
I'm sure you didn't read it carefully enough, _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Apr 26, 2010 6:30 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
yalmasri wrote: |
Now can anybody tell me what's going on? |
You're forgetting that DEFBIND is the default binding, not the actual binding. If you're getting unexpected results it's because that's what the application is asking for from the cluster. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Apr 26, 2010 7:22 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
yalmasri wrote: |
Default binding type is NOT FIXED and queue is persistent. |
Let me remind you: Queues are not persistent. Messages are. The persistency of messages is primarily enforced by the application and its configuration....  _________________ MQ & Broker admin |
|
Back to top |
|
 |
yalmasri |
Posted: Mon Apr 26, 2010 7:22 am Post subject: |
|
|
Centurion
Joined: 18 Jun 2008 Posts: 110
|
Quote: |
I'm sure you didn't read it carefully enough |
OK, you tell me, what is the queue level attribute that controls the weight of the total messages that should go to it?
Quote: |
DEFBIND is the default binding, not the actual binding |
Which is "NOT FIXED" in my case as I said.
I'm perplexed, this should be simple clustering scenario, I'm not using gateway queue managers or aliases or anything complex but still can't make it.  |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Apr 26, 2010 7:25 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
yalmasri wrote: |
Quote: |
I'm sure you didn't read it carefully enough |
OK, you tell me, what is the queue level attribute that controls the weight of the total messages that should go to it?
Quote: |
DEFBIND is the default binding, not the actual binding |
Which is "NOT FIXED" in my case as I said.
I'm perplexed, this should be simple clustering scenario, I'm not using gateway queue managers or aliases or anything complex but still can't make it.  |
Did you look at this link? http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzah.doc/qc12960_.htm  _________________ MQ & Broker admin |
|
Back to top |
|
 |
yalmasri |
Posted: Mon Apr 26, 2010 7:28 am Post subject: |
|
|
Centurion
Joined: 18 Jun 2008 Posts: 110
|
fjb_saper wrote: |
yalmasri wrote: |
Default binding type is NOT FIXED and queue is persistent. |
Let me remind you: Queues are not persistent. Messages are. The persistency of messages is primarily enforced by the application and its configuration....  |
Yes, I'm actually telling the application to take persistence from the queue configuration so effectively the queue is controlling this.
What do you think I'm doing wrong in the scenario I presented that made messages go to the remote queue and leave the local? |
|
Back to top |
|
 |
|
|
 |
Goto page 1, 2, 3, 4, 5 Next |
Page 1 of 5 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|