Enterprise Integration Zone is brought to you in partnership with:

Christian is a Principal Middleware Specialist/Architect at Red Hat specializing in developing enterprise software applications with an emphasis on software integration and messaging. His strengths include helping clients build software using industry best practices, Test Driven Design, ActiveMQ,Apache Camel, ServiceMix, Spring Framework, and most importantly, modeling complex domains so that they can be realized in software. He works primarily using Java and its many frameworks, but his favorite programming language is Python. He's in the midst of learning Scala and hopes to contribute to the Apache Apollo project. Christian is a DZone MVB and is not an employee of DZone and has posted 53 posts at DZone. You can read more from them at their website. View Full User Profile

Introducing Apache Apollo: Part I

08.23.2012
| 9145 views |
  • submit to reddit

Apache Apollo is the next-generation version of ActiveMQ built “from the ground up” on a core designed to be faster and scale better on multi-processor machines. ActiveMQ is one of the most popular open-source (if not the most popular) messaging brokers, and supports good performance, persistence messaging, high-availability, and networks of brokers. Most importantly, ActiveMQ has become very stable through all of its use, and we have been supporting some of the world’s biggest names in retail, banking, e-commerce and government that use it.

As great as ActiveMQ is right now, it has some complex threading implementations that keep it from being able to scale efficiently on higher-core, higher-resource machines. The threading implementation concerns are not around improper threading, but more that it was designed and developed at a time when there weren’t very many proven asynchronous java APIs and non-blocking IO libraries. Any application is susceptible to scalability concerns when there is shared state, contended synchronizations and exclusive locking.

However, ActiveMQ is good at what it does and since it’s stable right now, it would be a bad idea to re-write its threading architecture. So that’s where Apollo comes in: right now it’s a subproject of ActiveMQ where we can take all of the experiences of the ActiveMQ 5.x line, combine it with a new threading architecture, and develop a messaging broker that will meet demands of systems in the future with millions of destinations, hundreds of thousands of connections, high throughput, and utilize resources as efficiently as possible. Eventually, once backward compatibility is reached, Apollo will become ActiveMQ 6.0.

For those of you asking “Does that mean ActiveMQ is EOL?” The answer is emphatically “no”. ActiveMQ still has a very long life ahead of it, and as mentioned is being used by industry leaders. Bug fixes and support still continues for ActiveMQ through FuseSource (soon to be RedHat) and of course through the community. As long as there is interest in the community, ActiveMQ (or any Apache project) will not go away.

The goals of Apollo aren’t that far fetched, and it isn’t such a green project. It’s been worked on for over two years, had 6 candidates during its beta period, and v1.0 was released in February 2012. There are already quite a few people using it and are really putting it through the ringer. Hiram Chirino, the lead developer on Apollo, has also posted some very impressive benchmarks comparing Apollo with other mainstream message brokers: RabbitMQ, HornetQ, and ActiveMQ. See the stomp benchmarks here and the JMS benchmarks here.

At the time of this writing, Apollo has just released a new version, v1.4.

In part II, we’ll take a look at Apollo’s core threading architecture, hawtdispatch, Grand Central Dispatch, and some of the scalability and performance gains enabled by the new architecture. Stay tuned!

Published at DZone with permission of Christian Posta, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)