activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: HA system design
Date Thu, 08 Jun 2006 11:26:07 GMT
On 6/7/06, Thomas Swindells <> wrote:
> Hi, I'm new to JMS and ActiveMQ


> and need to develope a high available system.

Cool. BTW before we start there are quite a few different ways of
doing things & we've tried to make ActiveMQ flexible enough with
dealing with most things...

> I need a system without a single point of failure so I think I need multiple
> brokers. The system consists of multiple clients primarily subscribing to
> topics. If one of the broker goes down the subscribers need to be able to
> pick up from the other broker without loosing messages. Once the first
> broker has come back again it needs to keep functioning, again without
> loosing messages, if the second broker subsequentely dies.
> From what I have been reading the Master-Slave connection only supports a
> single failure occouring and then requires both brokers to be restarted, is
> this correct?


> If this is the case please could someone suggest to me what then is the best
> configuration in order to create a rebust high availability system?
> Are there any advantages/disadvantages to having embeded brokers within each
> client which then connect to the main broker system or should the client
> just connect directly to the main broker system?

So i'd recommend 2 approaches; it kinda depends on your requirements
really which is best. The easiest option to go with is Master/Slave.
The issue is if you loose a broker its currently a manual process to
bring it back online again since we don't yet have an automatic
old-master <-> new-master synchronization protocol.

The other option; if you're using topics and need really high
performance you could consider using   subscription recovery...

which basically means if a broker dies, you connect to another broker
(in a store/forward network so messages on a topic get replicated to
all available consumers). However by default you'd miss some messages
during the time between reconnecting & resubscribing, so subscription
recovery policy allows you to configure a buffer in each broker (say 1
minutes worth) of messages kept around in RAM so that they can be
replayed to any new retroactive consumers that reconnect.

The latter option is crazy fast and does not require any persistence,
the former option is the solution you should go with if you need
persistence or use queues.



View raw message