| Author |
Message
|
| Vitor |
 Posted: Fri Mar 27, 2009 4:37 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| shashivarungupta wrote: |
| I know the answer but against the architecture. |
Then it occurs to me you have an alternative. If the "standard" solution is in defiance of your architecture, you could replace the "standard" cluster processing. The workload balancing has an exit provided for this purpose and while I've never heard of it being used to explicitly route messages I don't see why (on the strength of nearly 5 mins thought!) an exit couldn't be written on that basis; neatly side-stepping the question of your dubious architectural decisions (made by others than yourself I feel sure) and the default round robin "not being up to the mark".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Mar 27, 2009 5:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Okay. How many Gateway qmgrs do you have? More than one?
If the reply messages are being sent correctly - that is the ReplyTo Queue is being MQOPENed with *both* a Queue and a Queue Manager Name (The MQReply node will do this automatically) - then MQ Cluster workload balancing will *not* apply.
The Cluster will be used to resolve where the ReplyToQmgr lives, and the messages will get sent over the cluster channels (and note! a disparity in volume between multiple requesters will cause a disparity in cluster workload balancing because clwl is done based on channel message count). But no workload balancing of the reply message will be done - because a) you don't *want* it done, and b) the message is fully addressed.
If the request messages are NOT being sent with a ReplyToQmgr, or if the Broker flow is NOT using the ReplyToQmgr to address the reply message, *then* cluster workload balancing will occur. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Fri Mar 27, 2009 3:54 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| mqjeff wrote: |
Okay. How many Gateway qmgrs do you have? More than one?
If the reply messages are being sent correctly - that is the ReplyTo Queue is being MQOPENed with *both* a Queue and a Queue Manager Name (The MQReply node will do this automatically) - then MQ Cluster workload balancing will *not* apply.
The Cluster will be used to resolve where the ReplyToQmgr lives, and the messages will get sent over the cluster channels (and note! a disparity in volume between multiple requesters will cause a disparity in cluster workload balancing because clwl is done based on channel message count). But no workload balancing of the reply message will be done - because a) you don't *want* it done, and b) the message is fully addressed.
If the request messages are NOT being sent with a ReplyToQmgr, or if the Broker flow is NOT using the ReplyToQmgr to address the reply message, *then* cluster workload balancing will occur. |
Thanks for detailed post.
Actually...
This is an active active scenario.
there are 2 gateway queue managers. 2 broker queue managers (on which brokers are defined).
Both the gateway queue managers are full repository. First is primary and other is secondary queue manager. Applications connect to primary gateway queue manager. In failure scenario it connects to secondary.
Request and Out queues are defined on the broker queue managers.
IN and Reply queues are defined on the gateway queue managers.
When an application connects to the gateway queue manager, it opens the request queue (whose alias is on broker queue manager and clustered. This physically on broker qmgr i.e. local queue) to put the message. cluster now places the message to the request queue from where broker gets the message using MQOPEN call (thats done by MQInput node.)
After processing, Broker opens the IN queue to puts the message (IN queue is on gateway qmgrs and clustered). Cluster does the routing of the message to any one of the instances of IN queue and target application is listening to both the instances to pick the message up.
This happens in the same way when target application connects to the gateway queue manager and tries to put the reply message on the Out queue(from where broker picks the message up) and forwards the message to the reply queue. The reply path is similar to the request path. (in terms of architecture)
When an application connects to the primary gateway queue manager and puts the message on the request queue, it mentions the ReplyToQueue as reply queue name and ReplyToQueueManager as primary gateway qmgr (where reply queue is physically defined.)
No Cluster workload exit is defined on the cluster. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Mar 28, 2009 1:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| shashivarungupta wrote: |
| No Cluster workload exit is defined on the cluster. |
My point was that, if you're dissatisfied with the way routing is being performed by the cluster, you could provide one. I wasn't suggesting you already had one.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Mar 28, 2009 1:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| shashivarungupta wrote: |
This is an active active scenario
...
First is primary and other is secondary queue manager. Applications connect to primary gateway queue manager. In failure scenario it connects to secondary. |
There are any number of posts in here describing the issues that arise from trying to use a WMQ Cluster for high availability (which it's not designed to do) rather than workload balancing (which it is).
It's also slightly confusing to refer to a full repository as a "gateway". Typically something refered to as a gateway is an machine that does not participate in the cluster, used to sidestep the restriction on v5.3 about local cluster queue instances.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Sat Mar 28, 2009 2:28 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
Going back a little, i'm not sure I agree with the point....
| mqjeff wrote: |
A Reply Message should *never* be cluster workload balanced.
|
In the case of a workflow engine as the requesting application, implementing a long running process (or even a sort one) its unlikely that the engine will do a get with wait for the reply. If there were multiple engines, either of them will probably be able to handle the response. Also if the originating QM was unavailble, waiting for that QM to come back could delay the message delivery longer than is needed. *Never* seems to be too strong a word.
I welcome your thoguhts  |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Mar 28, 2009 2:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| WMBDEV1 wrote: |
| I welcome your thoguhts |
I will raise a question on the difference between a REPLY message and a RESPONSE message. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Mar 28, 2009 4:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| WMBDEV1 wrote: |
| I welcome your thoguhts |
I will raise a question on the difference between a REPLY message and a RESPONSE message. |
There is a difference between a REPLY to a request which typically returns to the requestor, and a RESPONSE which could be distributed among targets.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Sat Mar 28, 2009 7:58 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Vitor wrote: |
| mqjeff wrote: |
| WMBDEV1 wrote: |
| I welcome your thoguhts |
I will raise a question on the difference between a REPLY message and a RESPONSE message. |
There is a difference between a REPLY to a request which typically returns to the requestor, and a RESPONSE which could be distributed among targets. |
A subtlety that may be wasted on me i'm afraid (and maybe the developers of MQ) as i'm not aware of a RESPONSE type of message, just REPLY (and the 3 others). Also some quick research of mr google shows these names used interchangably with wikipedia (not the most reliable sources agreed but please feel free provide a better one!) equating them. Whereas I understand the point you're trying to make, it is subtle and one that doesnt seem to be made by others when talking about request / reply scenarios.
Again, please feel free to disagree and show me otherwise.... These little debates are what interest me (but maybe we are going off topic now).
Cheers |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Sat Mar 28, 2009 9:25 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Quote: |
... Also if the originating QM was unavailble, waiting for that QM to come back could delay the message delivery longer than is needed. *Never* seems to be too strong a word.
|
I do agree with this statement.
Here comes the failover scenario. If the QM is unavailable then instead application unexpected delay, the other i.e. Secondary queue manager would deliver the message.
Now we can say reply queue can be shared in such scenarios. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Sat Mar 28, 2009 9:31 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Vitor wrote: |
| mqjeff wrote: |
I will raise a question on the difference between a REPLY message and a RESPONSE message. |
There is a difference between a REPLY to a request which typically returns to the requestor, and a RESPONSE which could be distributed among targets. |
Wow, I never knew that there is a thin layer between REPLY and RESPONSE.
 |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Sat Mar 28, 2009 9:48 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Vitor wrote: |
| shashivarungupta wrote: |
This is an active active scenario
...
First is primary and other is secondary queue manager. Applications connect to primary gateway queue manager. In failure scenario it connects to secondary. |
|
| Quote: |
It's also slightly confusing to refer to a full repository as a "gateway". |
"gateway queue managers" in our architecture refer to queue manager(s) to which applications connect to, to put the messages on the any instance of request queue that basically reside on the broker queue managers.
Its an architectural specific terminology.
queue manager can be FR or PR in a cluster. Is there any rule which to assign as FR and which to not? 
| Quote: |
Typically something refered to as a gateway is an machine that does not participate in the cluster, used to sidestep the restriction on v5.3 about local cluster queue instances. |
... I think cluster of the machines is different topic then the cluster of the mq queue managers. Though I have not worked on cluster of the machines/servers.  It would lead to different direction in all. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Sat Mar 28, 2009 10:27 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Quote: |
Is there any rule which to assign as FR and which to not?
|
Id expect to see two dedicated QMs acting as a Full Repository. By dedicated I mean they do not actually host application Local Queues (just information about those shared in the cluster). A Full Respository can be a FR for more than one cluster as needed.
| Quote: |
"gateway queue managers" in our architecture refer to queue manager(s) to which applications connect to
|
The usage of the term "Gateway" in this instance is not what I would have expected. A gateway, to me is normally the "hub" in the "hub and spoke" design or, a QM which is not in the cluster that allows an application to put messages to the cluster which I think is the point Vitor was trying to make.
| Quote: |
| I think cluster of the machines is different topic then the cluster of the mq queue managers. Though I have not worked on cluster of the machines/servers |
I dont think Vitor was talking about hardware clustering here and you may have got the wrong idea.
Did you manage to work out if the messages were originating from one QM more than the other as suggested?
If you just send a bunch of messages to the reply queue (Assuming correct MQOpen options) from the broker QM using something like RFHUTIL do you experience better workload management? |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Mar 29, 2009 1:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WMBDEV1 wrote: |
| A gateway, to me is normally the "hub" in the "hub and spoke" design or, a QM which is not in the cluster that allows an application to put messages to the cluster which I think is the point Vitor was trying to make. |
Eaxctly; it's the more traditional use of the term in WMQ circles.
| WMBDEV1 wrote: |
| Quote: |
| I think cluster of the machines is different topic then the cluster of the mq queue managers. Though I have not worked on cluster of the machines/servers |
I dont think Vitor was talking about hardware clustering here and you may have got the wrong idea. |
Partially. In this case shashivarungupta is trying to build a system where failover from his primary application queue manager to his secondary application queue manager is achieved using a WMQ cluster. My point is that WMQ clustering doesn't support that, it doesn't work very well and a high availability solution should be used instead.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Mar 29, 2009 1:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| shashivarungupta wrote: |
| In failure scenario it connects to secondary. |
And what happens to unprocessed messages on the primary?
| shashivarungupta wrote: |
| Though I have not worked on cluster of the machines/servers. It would lead to different direction in all. |
It would lead in the right direction.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
