activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastian Rodriguez <>
Subject Re: Running ActiveMQ and having a database failover
Date Wed, 14 Apr 2010 01:32:26 GMT
I'm not sure rather this solution can be used in your case. If you want to
use a primary / secondary db, you can normally specify them in the driver

<bean id="mssql-ds" class="org.apache.commons.dbcp.BasicDataSource"

        <property name="driverClassName"

        <property name="url"


This is the configuration for mysql for eg.
In your case, your primary and secondary db have the same IP. Maybe you can
consider this solution? :)

On 14 April 2010 01:33, icfantv <> wrote:

> We learned the hard way that using ActiveMQ with a database store doesn't
> play nicely with vacuums in that ActiveMQ uses open transactions to "lock"
> the relevant tables so secondary ActiveMQ servers wait to take over should
> the primary ActiveMQ server fail.  The open transaction causes vacuums to
> never finish - very bad on production databases.
> Learning from our mistakes, we set up a separate database server for use
> solely by ActiveMQ.  Now ActiveMQ can have open transactions to its heart's
> content and we don't care because we don't need to vacuum these
> tables...much, if ever.
> The problem we are facing now is that we run the ActiveMQ database server
> in
> a primary/secondary configuration such that if the primary fails, the
> secondary server gets the IP address of the primary and in theory, the
> service corrects itself.  However, ActiveMQ also doesn't appear to like
> having it's database connection ripped out from underneath it and instead
> of
> failing gracefully, it pukes and while the process still runs, it no longer
> accepts connections from ActiveMQ clients.  We have to physically kill the
> ActiveMQ process and restart it.
> Does anyone have a solution whereby we can use primary/failover database
> servers in conjunction with ActiveMQ such that ActiveMQ can recover without
> user intervention?  We are currently using ActiveMQ 5.1.
> Thanks,
> --adam
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

Sebastien Rodriguez

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message