Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
A Cassandra backed PersistenceAdapter for ActiveMQ
tree: 3341ac1ed8

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.


qsandra - A Cassandra backed PersistenceAdapter for ActiveMQ


While this adapter can be used against any existing cassandra installation, the goal is to provide an ActiveMQ broker cluster that is available across multiple datacenters, that can tolerate the loss of a datacenter with no impact on availability (like the existing ActiveMQ pure master-slave, except capable of more than 2 brokers/datacenters) while not having to bring the broker cluster down and copy data files around to restore a failed master (unlike the existing ActiveMQ pure master-slave), and have message state easily replicated to multiple datacenters without expensive database or storage software and hardware.




To configure ActiveMQ to use Cassandra for message persistence, you need to know a few pieces of information.

You need the host and port of whatever is doing cassandra thrift interface load balancing for you. If running more than one broker instance and using ZooKeeper for master election, you need your zookeeper connect string.

Here is an example spring config.

    <beans xmlns="" 

        <broker:broker useJmx="true" persistent="true">

                <ref bean="adapter"/>

                <broker:transportConnector name="tcp"


        <bean id="adapter" class="">
            <property name="cassandraClient" ref="cassandraClient"/>
            <property name="masterElector" ref="masterElector"/>

        <bean id="cassandraClient" class="">
            <property name="cassandraHost" value=""/>
            <property name="cassandraPort" value="9160"/>

        <bean id="masterElector" class="">
            <property name="zookeeperConnectString" 


The keyspace defined here needs to be deployed into your cassandra cluster, after you modify the ReplicaPlacementStrategy,ReplicationFactor,and EndPointSnitch appropriately for your use case


If you are using the ZooKeeperMasterElector, a persistent node will be created at /qsandra/, and ephemeral, sequential nodes willbe created under this node, so if you have multiple broker clusters using the same ZooKeeper, use appropriate chroot suffixes in the connect strings to partition the master election appropriately.


All of the usecases assume a familiarity with, or at least the willingness to learn, the techniques for running an Apache Cassandra cluster, and in cases where there is more than a single ActiveMQ broker (when using ActiveMQ failover://), Apache ZooKeeper, which is used to elect the master broker. (You can also write your own master election if you dont want to use zookeeper). Most of the work here is setting up Cassandra and ZooKeeper for appropriate replication and availablity.

Multi Datacenter HA ActiveMQ Broker Cluster

Due to the QUORUM mechanics of both Cassandra and ZooKeeper, to tolerate the loss of a datacenter while not impacting the availability of ActiveMQ there must be at least 3 datacenters involved in this configuration. Each datacenter needs at least one zooKeeper instance, and at least one cassandra instance.

So lets say we have 3 datacenters, with 1 ZooKeeper node, 2 Cassandra nodes and 2 ActiveMQ brokers per data center.

Use the DatacenterShardStragegy for replica placement, set the ReplicationFactor to 6, and the ReplicationFactor for each data center to 2.

With QUORUM ConsistencyLevel for reads and writes, reads and writes will succeed when 4 (ReplicationFactor / 2 + 1) reads or writes are successful. So this means if a datacenter is network partitioned or lost, we keep on trucking. Any 2 nodes of the 6 can be unavailable.

Similarly with Zookeeper, any 1 node of the 3 can be unavailable.

If the master broker is in the datacenter that dies, or is partitioned, one of the other brokers in the other datacenter will be elected master, and clients should fail over (using failover:// brokerURL)

Single Datacenter, Single Broker instance

This is a much simpler configuration. If a MasterElector is not set on the PersistenceAdapter, the broker will assume it is master.


There is a maven repo at that thankfully unpacks and deploys all the cassandra dependencies, so

    mvn clean install

should do it.

Something went wrong with that request. Please try again.