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: http://old.nabble.com/Running-ActiveMQ-and-having-a-database-failover-tp28233397p28233397.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
