Friday, February 03, 2012

Apache ActiveMQ Apollo 1.0 is released!

Apache ActiveMQ Apollo 1.0 has gone GA. Hiram Chirino does a great summary of features and functionality on his blog.

About 2 years ago, FuseSource started to think about the requirements of enterprise messaging systems for the next 10-15 years. There has been an exponential growth in the amount of data used by organisations over the past 25 years, and that trend is set to continue for the next 25. Once applications held megabytes of data, now they can hold petabytes (10^15). Within 5 years that will be zetabytes (10^21).  Speed of accessing that data is increasing, especially with the use of BigData (Apache Hadoop, Cassandra, MongoDB etc) - and so is the requirement for filling data stores with the vast volumes of data required.
Message-oriented middleware is all about transferring data reliably and as quickly as possible from one application to another. So it made sense for us to look at the requirements of the next generation of ActiveMQ with that in mind. We realised we would need to provide the following:

  • Extreme throughput
  • Scale to millions of dynamic destinations  for both point-2-point (Queues) and publish/subscribe (Topics).
  • Scale to 100,000 connections or more
  • Extensive protocol support (STOMP/OpenWire/MQTT/AMQP).

Apache ActiveMQ is performant, and provides extensive capabilities - but in its current architecture, its not going to meet the performance and scaling we required. ActiveMQ 5 is really stable - after being deployed in real world production environments, its become very battle hardened,  its not something we radically want to change. However, if you examine some of the internals of the current broker, you realise that there are too many points of synchronisation for ActiveMQ to scale up for the next generation of messaging problems that we will start to encounter in just a few years time.

It was decided early on that to help with scaling and concurrency, we should use a functional language -  which would help reduce side effects (and hence the need for synchronisation), and enable Apollo to maximise the utilisation of multi-core architectures. Currently, the Apollo broker is written in the Scala programming language. At the core of Apollo is the Grand Central Dispatch (GCD) technology  to help optimise support for multi-core.

The implementation of GCD, has been implemented by Hiram - and is called HawtDispatch.  ActiveMQ Apollo currently supports the STOMP protocol, but it does support JMS - using JMS over STOMP - there are performance comparisons here, which demonstrates Apollo's performance, even using a text based protocol its considerably faster than ActiveMQ 5 - which uses efficient data encoding based on OpenWire.

Right now ActiveMQ Apollo is a very performant message broker, that you should use if raw  performance is the overriding criteria of your architecture.  Later releases will be adding support for more protocols (MQTT, OpenWire, AMQP) and the enterprise features that will bring it in line with ActiveMQ 5. When this work is complete FuseSource will also provide a hardened supported version of ActiveMQ Apollo.


jamie said...

awesome work. I can't wait to try this out!

Mahesh said...

I was under the impression that Apollo will coexist with ActiveMQ. Especially, I read in the AMQ website that Apollo will form the core of AMQ6.0. Is this not true?