| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message affinity in Clusters |
« View previous topic :: View next topic » |
| Author |
Message
|
| smeunier |
 Posted: Thu Sep 14, 2006 6:59 am Post subject: Message affinity in Clusters |
 |
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
I have a situation where I'm trying to determine the best resolution to handling message affinities in a clustered environment.
The set up is 4 qmgrs (2 MVS and 2 AIX) in a cluster. Client makes request to a AIX Server and expects a reply from the same server.
Each of the AIX systems are running a instance of a broker.
When a client connects and send the reply out, the message will ne put on a cluster queues to the MVS servers for work load balancing. The MVS client needs to reply to the specific AIX instance it came from.
Originally I was thinking that the MVS client will determine by interrogating the ReplyToQmgr and issue an Open to the Qmgr and queue. This seems ok, but put additional logic on the MVS clients.
My though was, that if the Reply queue was clustered then any of the AIX queue manager could pick up the message(Message flow), determine if the current queue manager where it was received, is the queue manager, that it need to go to. If not, then route the message to the required queue manger by send it to a transmission queue to the other queue manager, where the client is waiting for the response.
I like this as routing business logic, is confined to the broker and not a client decision. But it may be over kill, and I'm not sure if I can extract the queue manager name from the environment where the message flow is running, to make this business logic decision.
Is the way out in left field, or should I stay with having the client making the reply determine what queue manager to send to? And am I right that I can just drop a message to a transmission queue or do I need to go through remote queue?
And yes I have read the books on clustering and message affinities. Just trying to make a decision based on experience in the field. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Sep 14, 2006 7:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The pattern says "use replytoqmgr".
If you don't want to use replytoqmgr, your next best bet is to use Pub/Sub.
Also, your description is horribly mangled between requester and replier and client and server. Request/reply clients don't send replies, the request/reply server does. So the process receiving the request is the SERVER and the process sending the request is the client.
In your design, either all of the "clients" have to be aware of each other or all of the "servers" have to be aware of each other - it's not clear which.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jeevan |
| Posted: Thu Sep 14, 2006 7:14 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| I do not know how you extract the queue manager name where the message flew and decide where should it go. But so far as the sending the message to the correct queue manager is concerned, you have to have remote queue and transmission queue, as this is sending /receiving taks. |
|
| Back to top |
|
|
| smeunier |
| Posted: Thu Sep 14, 2006 9:25 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Sorry Jeff, Let me try the scenario again to be more clear.
The clients(requestors), send messages to and AIX MQ Instance(awaits a response), where a message flow will perform some tasks, and forward on to a MVS MQ Instance(cluster workload management will alternate to which MQ Instance receives the request). The client on MVS end receives the message, extract data and must respond to the client on the MQ instance from where the message was generated(requested). The MQ Instances(2 MVS, 2 AIX) are in a MQ cluster. The AIX Message brokers, form a collective and are NOT cloned.
The requestors are not persistent, they are on demand requests, whose connectivity to the MQ AIX servers is determined by and Edge network dispatcher. This means that the reply from the MVS clients may need to go to either AIX MQmgr 1 or AIX MQmgr 2. In either case, the replies need to go back to the AIX MQMgr from where the request originated.
Hope this is a little clearer. Because the clients are not persistent on the requestor side, I think Pub/Sub process of registering/deregister is a little excessive, but in the long run, may not be more than the connection over head of the clients.
I guess it is important to note at this time, that the requestor clients are legacy apps, and complete redesign is not an option. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Sep 14, 2006 3:12 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay. So the broker flow is a proxy for the client.
In that case, you could even use Aggregation with a single request to maintain state for a client app. So an app would connect to some broker queue manager, which would invoke a local flow. That flow would use aggregation and the replytoqmgr to make sure that it got back the answer to it's particular proxied request. It could then reply to the queue on the local qmgr, and the client app would get it.
The client app would not have to set replytoqmgr -just the broker flow.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
