DPP's Blog

! 'ActiveMQ: not ready for prime time' May 25, 2011

I have been working with ActiveMQ for the last 6 months and I have come to the conclusion that ActiveMQ is not ready for prime time.

This post is a public version of private communications that I've made to FuseSource and some of the ActiveMQ committers.  By and large, the response has been either ignoring my feedback altogether or responding with "well, ActiveMQ is used by lots of very happy users, so you must be doing something wrong."

The particular use of ActiveMQ is a low volume (< 10K messages per minute) in a simple Java application environment.  ActiveMQ runs on a CentOS box with the latest JVM from Sun.  It's simple bread and butter stuff.  Nothing exotic.  The only requirement is high availability.

The issues I've seen with ActiveMQ are:

  • It's not correctly configured out of the box.  Basically, the start-up scripts don't allocate enough heap, test to see if there are enough file handles available on the system or do any of the things I'd expect the vendor of a nominally high performance/high availability piece of software to do.  Contrasting this with Tomcat and Jetty and PostgeSQL and Nginx... all of those packages install correctly out of the box without need for tuning to get them to work under moderate workloads.  It took me and 2 different ActiveMQ consultants 6 months to discover the issues with our ActiveMQ configuration (ActiveMQ itself, the JVM and the OS).
  • Most of the interesting features don't work or we have been warned not to use by FuseSource.  These include:
    • Temporary queues (they are not correctly deallocated by ActiveMQ and don't work on failover)
    • Network of brokers (you have to bake your own failover system by using external hardware load balancers and shared storage where the only way the slave knows it should be master is if a file lock is released)
    • Anything that streams bytes or sends non-trivial messages through the broker (apparently the whole broker stops if you send a 5MB blob through it until the blob is digested and sending streaming messages doesn't fail over correctly).

Now, ActiveMQ may work hunky dory in pub-sub mode, but having a simple durable message queue with high availability is not easy to do with ActiveMQ.

For those of you who don't know me, I invented the real time spreadsheet and helped financial services companies build systems that performed millions of automated trades a day. I run the Lift web framework project and have helped out the likes of Twitter and Foursquare building scalable systems.  I have some reasonable understanding of how to design and configure high performance, high reliability systems.  I'm not guy who just discovered message queues and was confused by how to run a start-up script.


Why am I writing a very negative piece?

I am writing this so that if you are considering ActiveMQ versus the numerous other open source message queues that you don't make the same mistake that I did... choose something else.