activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From magellings <>
Subject Re: JDBC Master Slave Cluster question
Date Wed, 21 Apr 2010 13:09:27 GMT

We run JDBC master/slave.  There isn't any message lost provided you use the
failover protocol on the client side.  When a message is sent to the broker
with the producer the broker sends an acknowledgment back when it has
persisted the message to the datastore.  When a consumer consumes a message
it's not until it sends an acknowledgement back to the broker that the
message gets deleted from the database.  So if the master fails over, the
slave has all the messages in the database.  This is true for queues and
durable subscriptions to topics.

I do believe the broker caches messages in memory for performance reasons,
but we have tested failing the brokers over with significant testing and
have not had message lose.  You will however get duplicate messages possibly
when a broker is failed over in which you'll need to use the EIP Idempotent
Consumer pattern to filter them out (if duplicates are a problem).

We use ActiveMQ 5.2 and NMS 1.1.

TonyTobin wrote:
> I am looking into clustering ActiveMQ brokers, the Master and Slave
> approach seems the best approach.
> One Master one or more slaves depending on the cluster.
> I have discounted the pure master slave since to restart the master you
> have to take the slave down.
> So I am looking at the JDBC Master Slave Cluster.
> If I understand it correctly. messages are sent to the master persisted to
> the database. If A Master goes down a slave that aquires the database lock
> takes over.
> What happens to messages still in the queues that have not yet been
> persisted being recieved or sent.
> Are they lost, can a slave be configured to take over the Masters queues,
> does this happen automatically.
> Are there any links that cover clustering in depth.
> Thanks for any help
> Tony

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message