Enterprise Integration Zone is brought to you in partnership with:

I am the founder and lead developer of Hibernate Envers, a Hibernate core module, which provides entity versioning/auditing capabilities. I am also one of the co-founders of SoftwareMill, a company specializing in delivering customized software solutions (http://softwaremill.com, "Extraordinary software as a standard"), based on Java and JBoss technologies. After work, apart from being involved in development of Envers, I work on several small open source projects, like ElasticMQ (simple message queue written in Scala with an SQS interface), projects around static analysis (using JSR 308 - Typestate Annotations/ Checkers Framework and FindBugs), and some CDI/Weld (not always portable) extensions, like autofactories or stackable security interceptors. I am also interested in new JVM-based languages, especially with functional elements (like Scala, JRuby) and frameworks built using them (like Lift), as well as improving the ways we use Dependency Injection. Adam is a DZone MVB and is not an employee of DZone and has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

ElasticMQ 0.5 Release: Journalling, Stand-alone Server

  • submit to reddit

ElasticMQ is a message queue server, with Scala, Java, and an Amazon SQS-compatible interface. It also supports guaranteed messaging via replicating the messages across a cluster of servers.

The new 0.5 version brings two major features. Firstly the file-log, that is a journal for operations on the queue&message storage. Using it makes most sense with the in-memory storage, as the DB storage has its own persistence. Thanks to the journal you can make sure that you won’t loose messages across server restarts, when moving the whole server etc. The file log uses only append operations to write to files, making it pretty fast (no random access). However, writing the journal is an asynchronous process, so on a server crash some data could be lost (why making this synchronous wouldn’t help much – see the README). If you require an even higher level of message durability, use replication.

Of course, replication can be combined with journalling, providing a server where your messages are safe both when stopping and starting the whole cluster, and in case of an individual node crash.

The second feature is (finally!) a stand-alone server distribution. You can download a .tar.gz or a .zip archive. Running the server is very easy, you just need to unpack it and execute the provided run.sh or run.bat script.

Configuration is done in a type-safe way (via Ostrich). You can specify which storage to use (in-memory or DB-backed), should the file log be used, if and how to setup replication and node discovery, and whether to expose an SQS interface. The configuration file is self-documenting, see the base class and the default config file.

Have fun!


Published at DZone with permission of Adam Warski, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Daniel Slazer replied on Tue, 2012/06/12 - 12:14pm

I have turned down work where after explaining to a potential customer that what he is asking for makes no sense he continues to ask for it. I let someone else get the bad press.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.