Architecture

Apollo started as an experiment to see what it would take to make ActiveMQ work better on machines with higher core counts. It has resulted in broker that is much more deterministic, stable, and scaleable.

Architectural Changes

The major fundamental architectural changes it brings are:

Reactor Based Thread Model

Apollo uses HawtDispatch to implement the sever using a multi-threaded non-blocking variation of the reactor design pattern. HawtDispatch is a Java clone of libdispatch (aka Grand Central Dispatch). It uses a fixed sized thread pool and only executes non-blocking tasks on those threads.

The thread model allows Apollo to reach very high levels of scaleability and efficiency, but it places a huge restriction on the developer: all the tasks it executes must be non-blocking and ideally lock-free and wait free. This means that the previous ActiveMQ broker architecture had to go through a major overhaul. All synchronous broker interfaces had to be changed so that they would instead return results via asynchronous callbacks.

Scala 2.8 Implementation

Even though Apollo started as a fork of ActiveMQ 5.x, the new reactor design restrictions required major changes from the network IO handling, to the flow control design, all the way to the Store interfaces. Scala provided a much more concise way to express callbacks, namely by it's support for partial functions and closures.

Protocol Agnostic

ActiveMQ has supported multiple protocols for many years, but under the covers what it's doing is converting all the protocols to use the OpenWire messaging protocol. Naturally, this approach is not optimal if you want to efficiently support other protocols and not be limited by what OpenWire can support.

The Apollo server is much more modular and protocol agnostic. All protocols are equal and are built as a plugin to the the broker which just make use of exposed broker services for routing, flow control, queueing services etc. For example, this means that messages will be persisted in a Store in the original protocol's encoding. There is no protocol conversion occurring under the covers unless it is required.

REST Based Management

ActiveMQ choose to exposed it's management interfaces via JMX. JMX was a natural choice since ActiveMQ is Java based, but JMX has a couple of serious limitations:

Apollo exposes a rich and detailed state of the sever using REST based JSON or XML services.