ActiveMQ Apollo is a new generation of messaging broker built from the foundations of the ActiveMQ messaging broker, but using a radically different threading and message dispatching architecture.  In it’s current incarnation, Apollo only supports the STOMP protocol but just like the original ActiveMQ, it’s been designed to be a multi protocol broker and in future iterations it should get OpenWire support so it can be compatible with ActiveMQ 5.x JMS clients.

The BIGGEST change in the broker architecture was a switch to a non-blocking threading model for message processing using the HawtDispatch library.  This meant changing many of the APIs to using a continuation passing style so that caller never blocks on a request.  The upside of the new architecture is that the most complex and brittle areas of multi-threaded code in ActiveMQ 5.x  have now been tremendously simplified.  Those areas are using actor style coarse grained synchronization thanks to HawtDispatch.

It is impressive how well Apollo performs. Using a little benchmarking tool, I compared the performance of Apollo and three other STOMP server implementations.  The benchmark tests different combinations of consumers, destinations, producers, persistence options, message sizes for a total of 74 common usage scenarios.  I ran the benchmarks on two different boxes.  If you want to peek at the complete benchmark reports, see Ubuntu 4 Core report and OS X 8 Core report.

Apollo ends up doing really well in comparison to other servers in most cases but in some cases it’s just mind blowing.  For example:

The  scenario above is the case where you have 10 producer and 10 consumers on a single topic moving non persistent STOMP messages with a 20 byte payload.   The graph shows that Apollo can easily sustain a total consumer processing rate of 1.2 Million messages per second while the closest contender could only reach about 105,000 thousand messages per second.