ElasticMQ is a message queue system, with Java, Scala and an Amazon SQS-compatible REST interface.

The 0.4 release brings a new major feature: data replication. You can now setup a cluster of ElasticMQ nodes, and have each queue and message replicated across this cluster. Each node can use either the in-memory storage, or the DB-backed storage. This enables a wide range of deployment scenarios, e.g.:

• in-memory storage, single node: ideal for testing (ElasticMQ is easily embeddable and can be used to test applications which use Amazon SQS in production)
• db storage, multiple nodes, single shared database
• in-memory storage, multiple nodes, replication: good if at least one node is always alive
• local db storage, multiple nodes, replication: each node has its own persistance. Data safety without the need to setup a clustered database

Depending on how safe you want to be from loosing a message, there’s a variety of replication modes to choose from:

• fire-and-forget: data replication is done in the background
• wait for at least one cluster member to acknowledge that it received the message
• wait for a majority of members
• wait for all members

See the README for more details. Starting to use ElasticMQ is really simple!

Clustering is implemented using JGroups (thanks to Bela for the help on the forums!). The cluster can be configured using a standard JGroups configuration file, which means you can either use the UDP stack with multicast discovery, TCP stack with a list of initial node IPs, AWS discovery, and so on. ElasticMQ doesn’t require any particular JGroups configuration so you are free to use whatever suites your deployment best.

Please note that the replication feature is still at an experimental stage, so bugs (as always) may happen :).

Feedback welcome!

Adam