| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Cluster receiver priorities: glitch? |
« View previous topic :: View next topic » |
| Author |
Message
|
| svu |
 Posted: Tue Jun 07, 2011 11:36 am Post subject: |
 |
|
Voyager
Joined: 30 Jan 2006
Posts: 99
|
| PeterPotkay wrote: |
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzah.doc/qc10940_.htm
Look at #8 and # 9.
|
Thank you VERY MUCH! I guess this is the ultimate answer to the question! |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Tue Jun 07, 2011 11:59 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
This is not a 100% bullet proof solution. You WILL find messages going to the wrong QM sooner or later when you don't want them to.
|
I'm going to quibble just a bit about the bold portion of your reply.
By any reasonable definition of an mq cluster, there are only right qmgrs. A qmgr or channel or queue with lower rank or priority, or a qmgr that is quiesced, is just less right than the others.
The objective of the algorithm is to find best fit at that instance. There are no absolute guarantees as to exactly how many, and to which queues, msgs will be distributed.
We've discussed many, many times what channel states RUNNING and INACTIVE indicate; and neither indicates that the next message put will be successfully transmitted. Clustering cannot improve on this. MQ clusters only offer alternate destination queues; and, with v7, some tools to suggest which queues you would prefer messages go to.
_________________
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 |
|
|
| Vitor |
| Posted: Tue Jun 07, 2011 12:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| PeterPotkay wrote: |
This is not a 100% bullet proof solution. You WILL find messages going to the wrong QM sooner or later when you don't want them to.
|
I'm going to quibble just a bit about the bold portion of your reply. |
I'm going to quibble about your quibble.
Whilst you're perfectly correct that a WMQ cluster only ever routes messages to valid targets that meet the criteria of the workload balancer (and I'll accept your shorthand of "the best fit"), the OP has a 2 queue manager scenario where there is a "right" queue manager (the active) and a "wrong" queue manager (the hot standby). Messages are expected on the "right" one and not on the "wrong" one.
So it's valid to describe the OP's scenario that way. And it's in this semantic quibble that the OP's HA solution has rather come unstuck. Because he's trying to route messages to the"right" one but the cluster is routing them to the "best" one. Where the criteria for "right" and "best" did not align in 2 cases.
Next week's debate - did Shakespear really write all those plays himself and who cares? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 07, 2011 12:11 pm Post subject: Re: Cluster receiver priorities: glitch? |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Vitor.
Actually,
| svu wrote: |
There are 2 QMs, with cluster receiver channel priorities 5 and 3, identical sets of clustered queues. The 2nd QM is considered as a hot spare.
|
Considered a hot spare by who/what/whom?
If it's just another qmgr that is part of the cluster, then it is part of the cluster - and subject to being chosen as a destination.
To ensure that it isn't chosen, put-inhibit the queue, or SUSPEND the qmgr, or something else that will be seen by the other qmgr (or qmgrs in a cluster) that it is no longer interested in playing cluster.
[edit]
Even rank or priority of zero does not eliminate a destination.
[/edit]
_________________
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.
Last edited by bruce2359 on Tue Jun 07, 2011 12:18 pm; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jun 07, 2011 12:16 pm Post subject: Re: Cluster receiver priorities: glitch? |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
To ensure that it isn't chosen, put-inhibit the queue, or SUSPEND the qmgr, or something else that will be seen by the other qmgr (or qmgrs in a cluster) that it is no longer interested in playing cluster. |
Suspending the QM wouldn't ensure that the QM isn't chosen.
My earlier sentence might better be stated as:
You WILL find messages going to the unintended QM sooner or later when you don't want them to.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 07, 2011 12:30 pm Post subject: Re: Cluster receiver priorities: glitch? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Considered a hot spare by who/what/whom? |
By the OP in this instance.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 07, 2011 1:41 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Hot spare has another meaning in HA-speak. Clusters are not HA.
The OP can consider the qm as hot spare, warm spare, tepid spare, or whatever; but to clustering software, it is just another candidate for sending messages.
_________________
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: Tue Jun 07, 2011 8:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You can however control this somewhat
If you set the hot spare to suspended in the cluster, the likelyhood that you will get a message on it is quite small, if the queue has an instance on a non suspended qmgr that is not excluded from the algorithm (not put inhibited...)
You could say that messages will then go to the "hot spare" only if there is no instance of the queue available on a non suspended qmgr at the instant the load balancing algo makes its decision.
Note the difference between a running channel and a starting channel (status bindings) will influence the algorithm.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
