Apollo is a next generation message queuing solution. Hiram Chirino, Apollo project lead and fellow at FuseSource, recently posted some impressive Apollo benchmarks against RabbitMQ, HornetQ, and ActiveMQ. The benchmarks indicate that Apollo will be on a lot of developer's roadmaps for messaging.
Apollo is a rewrite of ActiveMQ. Apollo's goal is to be faster, more reliable, and easier to maintain. The current benchmarks seem to indicate that this goal has been reached.
Apollo uses a significantly different threading and message dispatching architecture. Currently Apollo only supports the STOMP protocol. The STOMP protocol is a wire protocol for messaging that is supported by 20 different clients and 11 servers (clients for C, C#, C++, Objective C, Ruby, Python, Perl, and more). Future versions will support OpenWire protocol. OpenWire is the wire protocol supported by ActiveMQ which has clients written in C, C++, and C#. Apollo was designed to be compatible with the possibility of adding AMQP later.
Apollo uses a Reactor Based Thread Model and it uses the HawtDispatch project. HawtDispatch is modeled after the libdispatch API. The libdispatch API powers the Grand Central Dispatch (GCD) technology in OS X. GCD was developed by Apple Inc. to optimize support for multi-core processors. GCD allows routing which means parallel running tasks are queued up for execution. When processing resources become available the tasks are scheduling to execute on available processor cores.
The improved thread model allows Apollo to perform really well. But the new thread model means all tasks must execute non-blocking, lock-free and wait free. This forced ActiveMQ broker to be drastically rewritten to support the new thread model. What started out as a fork of ActiveMQ ended up being a major rewrite.
The new broker code is written in Scala 2.9. Scala was chosen because it was deemed a more concise way to implement async callbacks. Apollo uses Scala's support for partial functions and closures.
Hiram explains the benchmarks and put the code for the benchmarks in GitHub. He ran the tests in several environments including Amazon Linux: EC2 High-CPU Extra Large Instance, Ubuntu 11.10: Quad-Core Intel 2600K (3.4 GHz), and OS X: 2 x Quad-Core Intel Xeon (3 GHz).
InfoQ got a chance to catch up with Hiram and get his thoughts on Apollo, STOMP, AMQP and the benchmarks.
InfoQ: Why does ActiveMQ need a new version? and what is Apollo?
I am always looking at how we can improve ActiveMQ in future versions. I thought that using a Grand Central Dispatch (GCD) style threading API could provide significant improvements in ActiveMQ's performance on multicore machines with large numbers of active connections and destinations. GCD style threading allows ActiveMQ to run with a constant number of threads and with little contention even when a single resource like a queue is being highly contended by multiple clients.
By starting a subproject, we can work on a future generation of ActiveMQ without disrupting our current user base. So far, the results have been very impressive, and we have a lot of interest in the subproject. Sometimes a subproject will be rolled into the core project as a capability, and other times like with Apache Camel, a subproject grows to become a complementary project.
InfoQ: Are you satisfied with Apollo progress? Can you briefly describe how it did in the benchmarks?
I am extremely satisfied. The STOMP benchmarks I've run show that Apollo is competitive with all the major STOMP servers on the market and in messaging scenarios where there is contention on a single queue or topic, it does significantly better than the competition. This is a great validation of the decision to use a GCD style threading architecture.
InfoQ: Why does Apollo only support STOMP?
STOMP is a messaging protocol which shares many of the same design principles as HTTP. Since it's text based and simple to parse, a large organic community of cross language clients and servers have sprung around STOMP which makes it an ideal protocol to use when you need to do asynchronous messaging across many languages and platforms. ActiveMQ was one of the first severs to support STOMP, so it was natural that STOMP would be the first protocol which Apollo implemented since it is simple yet still exercises all the core messaging concepts of a messaging engine.
Protocols are pluggable in Apollo. We have already started working on an implementation for main protocol which ActiveMQ uses which is Openwire. Once the Openwire protocol is fully implement and a couple of more features are added in, we will be able use Apollo to power the next major release of ActiveMQ.
InfoQ: What is your relationship to the Apollo project?
I'm the founder of the Apollo subproject and PMC chair of the ActiveMQ TLP.
InfoQ: Why doesn't ActiveMQ and/or Apollo support AMQP?
Members of the ActiveMQ team have been following the AMQP specification, but is has continued to change dramatically while under development. Now that AMQP 1.0 has finally been released and backwards compatibility it is possible, we will be looking at adding support for AMQP. Apollo has been architected in such a way that it can support AMQP, which as a specification puts a lot of requirements on the server architecture.
InfoQ: What advantages does OpenWire have over AMQP? Do any other projects besides ActiveMQ support OpenWire?
OpenWire allows ActiveMQ to implement the full JMS specification including distributed transactions using XA. It has native Java, C++, and .NET clients with automatic connection failure handling/recovery so that applications don't have to implement failure recovery logic. The downside is that it's only been adopted by the ActiveMQ messaging server.
InfoQ: What advantages does STOMP have over AMQP?
STOMP is simpler to parse and understand than AMQP. Like HTTP, a TCP stream of a STOMP client and server are easy for a human to visually inspect and understand. That makes implementing interoperable clients and servers simple. Stomp has 10 servers, and over 20 client implementations avail for a variety of clients and servers. STOMP also gives you a large amount of flexibility. It does not force servers to implement particular messaging semantics. While most severs implement queue and topic style semantics, they are free to implement additional delivery and routing semantics that may be useful to their users.
