ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General Discussion » One for the expereinced system setup folks

Post new topic  Reply to topic
 One for the expereinced system setup folks « View previous topic :: View next topic » 
Author Message
vanwilder
PostPosted: Mon Oct 24, 2005 2:13 am    Post subject: One for the expereinced system setup folks Reply with quote

Newbie

Joined: 06 Sep 2004
Posts: 6
Location: South Africa

Hey guys

I have a scenario which I would appreciate some advice / recommendations on etc.

Quick overview of the existing setup:

Operating environment = AIX
WebSphere MQ 5.3

I have three WEB machines which connect to a central application machine and send and receive messages via MQ client and a server connection channel. The central application machine has MQ server installed and hosts a number of local queues.

We have decided to upgrade the three WEB machines from MQ client to MQ server as the application on the WEB machines has a potential of loosing messages with MQ client.

The three WEB machines will all post messages to a single queue on the application machine. The application on the application machine will pick up these messages and process them and then send acknowledgements back to the WEB servers. However, the application can only send acknowledgements to a single queue and not to the specific WEB machine where the message originated from. This is not a train smash as we can route responses to one single queue manager as all the data from the application on the WEB machines is stored in a central database so it does not really matter through which WEB machine the response is processed.

The problem is that should there be an outage on the specific WEB machine which processes the responses, these responses will build up on the transmission queue of the application machine until the WEB machine has been restored. This delay or risk is not acceptable to the business so we need to identify a solution that will guarantee response message deliveries to the specific WEB machines.

With the platform being AIX the first solution that came to mind was to setup some HA fail-over between two of the three WEB machines so that if an outage should occur on let's say WEB1, we can then fail-over the MQ and application resource over to WEB2 to assure that responses still get delivered and processed.

This will work but HA takes time to setup and test of course so I'm fishing around for a simpler solution.

I have never done this and don't know if it is possible, but if I keep the response messages on a local queue on the application machine, is there no way I can connect to that local queue via some sort of remote queue definition and pick the message up of that local queue? Keeping in mind this will be MQ server to server now.

Any responses will be appreciated.

Regards
VW
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Mon Oct 24, 2005 2:58 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

If you don't care which machine processes the acknowledgements, then process acknowledgements on all three machines.

Cluster all 4 qms, and share an instance of the acknowledgement queue in the cluster from each WEB machine.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
harry_hotdog
PostPosted: Mon Oct 24, 2005 3:19 am    Post subject: Reply with quote

Novice

Joined: 19 Oct 2005
Posts: 10
Location: England

[quote].. the application on the WEB machines has a potential of losing messages with MQ client.
[/quote]

How does that happen?
Surely only with rather sloppy programming, getting msgs outside syncpoint.
Better to tidy up your apps than go the expense and bother of setting up more servers, even if you do cluster them like jeff suggests.
Back to top
View user's profile Send private message
vanwilder
PostPosted: Mon Oct 24, 2005 5:31 am    Post subject: Reply with quote

Newbie

Joined: 06 Sep 2004
Posts: 6
Location: South Africa

Jeff,

Problem with clustering all 4 qmgrs is that application machine already consists of a HACMP cluster setup between two boxes. What about clustering the 3 WEB boxes? Surely then I can send responses to one central queue shared within the cluster?

Harry,

Don't even get me started on the sloppy coding. As usual the developers have been lazy and now we have to perform miracles.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Mon Oct 24, 2005 5:41 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

vanwilder wrote:
Problem with clustering all 4 qmgrs is that application machine already consists of a HACMP cluster setup between two boxes.
MQClustering is unrelated to HACMP clustering.

vanwilder wrote:
What about clustering the 3 WEB boxes? Surely then I can send responses to one central queue shared within the cluster?

Yeah, but now you have to gateway the app server to the web cluster - and that ends up with a single point of failure (the gateway qmgr).
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General Discussion » One for the expereinced system setup folks
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.