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.