| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Cluster - programming impact |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqnomad |
 Posted: Wed Apr 28, 2010 6:45 am Post subject: Cluster - programming impact |
 |
|
Acolyte
Joined: 18 Mar 2010
Posts: 53
|
How have clusters been introduced at clients as far as application changes?
I have looked thru some of the entries here and the cluster manual.
Looking at an established architecture, large international client. After some changes, they are in a situation that they don't have real HA - now, I'm not confusing clustering with HA ... but they are expecting a surge of messages from a business partnership.
It is also my understanding that there are some changes in HA capabilities for a Linux environment ... just an extra point here.
At this time there are *no* multiple messages where message sequence is an issue.
My thought would be to introduce MQ clusters to handle the higher capacity of messages, then have the clusters with HA capabilities for recoverability.
The applications get messages by correlation ID - so my understanding is that to get a reply they would have to know the queue manager name. Please make any corrections to this statement.
How have clusters been introduced at clients as far as application changes? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Apr 28, 2010 7:08 am Post subject: Re: Cluster - programming impact |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqnomad wrote: |
| The applications get messages by correlation ID - so my understanding is that to get a reply they would have to know the queue manager name. Please make any corrections to this statement. |
The major correction here is that cluster's don't affect applications. An application always connects to a queue manager; that queue manager may or may not participate in a cluster but that's nothing to the application. If you want an application to connect to different queue managers based on availability that's a job for a CCDT.
In the example you quote a request would be put via a given queue manager, traverse the cluster to an instance of the replying app and this would send a reply just as if the message had arrived via point to point, using the Reply details in the MQMD, and return back to the original sending app.
So introducing a cluster shouldn't have any impact on well behaved applications that are using the system facilities.
There have been discussions on client connections for failover using CCDT in here you might find useful
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqnomad |
| Posted: Wed Apr 28, 2010 9:11 am Post subject: |
|
|
Acolyte
Joined: 18 Mar 2010
Posts: 53
|
Thank you - I will search for the CCDT entries.
Need to get add'l clarification, but the way they describe this working is that the server calls back to "pull" these replies from the queue (assume the queue indicated by replytoq) using correlid - but if the replies are in a different queue manager then they will need to change the application. I find this a little strange, but this is how they describe it. I do not know where they're keeping this correlid - another question I need to ask. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 28, 2010 9:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqnomad wrote: |
| the way they describe this working is that the server calls back to "pull" these replies from the queue (assume the queue indicated by replytoq) using correlid |
Well if they expect the replies to be in the queue indicated by the replytoq then logically they should expect them to be in the instance of that queue hosted by the replytoqmgr. Remember both of these fields are under the control of the requesting application (though the replytoqmgr does default to the putting queue manager).
I accept that logic sometimes has very little to do with design.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
