In ActiveMQ 5.9, the Replicated LevelDB Store is introduced. It handles using Apache ZooKeeper to pick a master from a set of broker nodes configured to replicate single LevelDB Store. Then synchronizes all slave LevelDB Stores with the master keeps them up to date by replicating all updates to the master. This might become the preferred Master Slave configuration going forward.
In ActiveMQ 5.8, the LevelDB Store was introduced. The LevelDB Store is a file based persistence database. It has been optimized to provide even faster persistence than KahaDB. Although not yet the default message store, we expect this store implementation become the default in future releases.
From 5.3 onwards - we recommend you use KahaDB - which offers improved scalability and recoverability over the AMQ Message Store.
The AMQ Message Store which although faster than KahaDB - does not scales as well as KahaDB and recovery times take longer.
For long term persistence we recommend using JDBC coupled with our high performance journal. You can use just JDBC if you wish but its quite slow.
Our out of the box default configuration uses Apache Derby as the default database, which is easy to embed - but we support all the major SQL databases - just reconfigure your JDBC configuration in the Xml Configuration.
High performance journal - ActiveMQ 4.x
To achieve high performance of durable messaging in ACtiveMQ V4.x we strongly recommend you use our high performance journal - which is enabled by default. This works rather like a database; messages (and transcation commits/rollbacks and message acknowledgements) are written to the journal as fast as is humanly possible - then at intervals we checkpoint the journal to the long term persistence storage (in this case JDBC).
Its common when using queues for example that messages are consumed fairly shortly after being published; so you could publish 10,000 messages and only have a few messages outstanding - so when we checkpoint to the JDBC database, we often have only a small amount of messages to actually write to JDBC. Even if we have to write all the messages to the JDBC, we still get performance gains with the journal, since we can use a large transaction batch to insert the messages into the JDBC database to boost performance on the JDBC side.
Our journal is based on lots of the great work in the Howl project; we keep close ties to the Howl community. However since ActiveMQ has to handle arbitarily large message sizes, we've had to make our journal handle any size of message and so we don't use the fixed size record model that Howl uses.
For full explict control over configuration check out the Xml Configuration. However a quick way to set which persistence adapter to use is to set the following system property to be the class name of the PersistenceAdapter implementation.
When running the broker from the command line, we look for the activemq.xml on the classpath unless you specify one to use. e.g.
Here is a sample XML configuration which shows how to configure the journal and the JDBC persistence.
For more details see the Initial Configuration guide.
JDBC Persistence without Journaling
To enable JDBC persistence of JMS messages without journaling, we need to change the message broker's default persistence configuration from
For AMQ 3.x
Make sure to send durable messages so that it will be persisted in the database server while waiting to be consumed by clients. More information on configuration JDBC persistence at JDBC Support
Disaster Recovery options
If you don't want persistence at all you can disable it easily via the Xml Configuration. e.g.