Exploring ActiveMQ Artemis

ActiveMQ Artemis, the heir-apparent to ActiveMQ 5, marks a substantial departure from its predecessor. But is it ready for use in mission-critical applications?

In this blog, we discuss the history of the ActiveMQ project, the differences between ActiveMQ Artemis vs. ActiveMQ, and considerations for teams who want to use Artemis in production.

• What Is ActiveMQ Artemis?
• ActiveMQ Project History
• Apache ActiveMQ Artemis vs. ActiveMQ
• Is ActiveMQ Ready Production Ready?
• Final Thoughts
• Additional Resources

What Is ActiveMQ Artemis?

ActiveMQ Artemis is a next generation messaging broker that is designed to replace ActiveMQ 5.

A Brief History of the ActiveMQ Project

The Apache ActiveMQ project has had an interesting history. It began as the messaging core for the Apache Geronimo project. Geronimo, now a collection of Java EE / Jakarta EE libraries, was once envisioned as a full Java EE application server, likened to Wildfly. Though the Geronimo server would not see wide adoption, ActiveMQ became wildly popular as a message broker and became its own top-level Apache project.

ActiveMQ is now moving from major release 5 to 6, and not without some consternation within the community. ActiveMQ 5 has been the prevailing major release for well over ten years, providing a reliable and proven implementation of the JMS 1.1 specification, alongside a host of other features that made it the clear choice for enterprises seeking a feature-rich and production-ready messaging solution.

A complete rewrite of the messaging core was performed for ActiveMQ 6, using the Java implementation of Apple’s libdispatch library, HawtDispatch. This project, labelled ActiveMQ Apollo, promised to envision ActiveMQ from the ground up as a completely asynchronous, non-blocking architecture.

ActiveMQ Artemis and ActiveMQ Apollo are both derived from Greek mythology. Artemis was the Greek goddess of the hunt, while Apollo (her brother) was the Greek god of the sun.

The project seemed promising, and quite a bit of work and investment was done on ActiveMQ Apollo. It even reached 1.x status, and some adoption was seen. The project reached version 1.7.1 before, seemingly out of nowhere, it was deprecated in favor of a new ActiveMQ effort, dubbed ActiveMQ Artemis.

On July 8th, 2014, long-time ActiveMQ committer Clebert Suconic issued the following statement to the ActiveMQ community:

To understand why this donation made sense at the time, we need to look just a little further back in ActiveMQ’s history, when it was adopted as part of the Apache Servicemix project. Apache Servicemix is a full-fledged ESB solution that takes advantage of Java OSGI microservice architecture. The project itself is a combination of four top-level Apache projects: Apache Camel, Apache Karaf, Apache CXF, and Apache ActiveMQ. This approach to ESB architecture caught the attention of FuseSource, a company owned, at the time, by Progress Software.

FuseSource hired several of the original ActiveMQ committers, as well as committers from the related Apache Camel project, and those working on Servicemix. The “Fuse” branch of Servicemix was then created, which promised more regular releases, with expertise delivered by the original committers of the ActiveMQ and Camel projects. Progress was known for its OpenEdge / WebSpeed 4GL enterprise database languages, as well as it’s still-used JMS implementation, SonicMQ. This ownership would prove to be short-lived, however, as Red Hat ultimately acquired FuseSource from Progress in 2012 and created the JBoss Fuse ESB product from it.

This left Red Hat in the rather undesirable position of maintaining two separate message broker projects, the existing HornetQ project which was the JMS component for the JBoss Java EE application server, and now ActiveMQ as part of its Fuse acquisition. The solution then was, as Suconic put it, to “build one truly great JMS broker.”

The result of that effort is the Apache Artemis project, and the subsequent deprecation of the Apache Apollo project. The Apollo code is still kept for posterity here.

ActiveMQ Applied: Real-World Use Cases

Want to learn more about ActiveMQ? Watch the webinar below to discover the benefits of ActiveMQ as a message broker, how and when it can be implemented for maximum success, and considerations for maintaining security and performance with ActiveMQ.

Apache ActiveMQ Artemis vs. ActiveMQ

While Artemis is envisioned as a drop-in replacement for ActiveMQ 5, under the hood it is a completely different messaging platform. The ActiveMQ community has done an impressive job of creating abstraction layers that make the code integration experience very similar, and the project is seeing plenty of activity. You can check out the GitHub Pulse here.

That said, there are still bits of missing functionality, as well as fundamental architectural differences, that should be understood.

Address Model

One of the first changes to get used to is the disappearance of traditional topics from the messaging model. Whereas JMS users were used to dealing with two messaging patterns, FIFO queues with load balancing consumers, and publish-subscribe topic patterns, Artemis has rethought this pattern altogether in order to present a universally abstracted messaging model. Don’t worry, the functionality has been normalized for you, so you can still create topic patterns in your application code and even reference the JMS API to do so. 

In Artemis, message destinations are called “addresses” and they represent an endpoint to which a client should connect. This address is associated with 0 or more queues, and the behavior of messages with respect to those queues is determined by the addresses “routing type.” So, that’s three components to the model, “addresses,” “queues,” and “routing types.”

Artemis supports two routing types, which equate to traditional queues and topics respectively. 

The first is called “anycast”, which denotes that the message should go to one and only one queue associated with the message. In turn, that queue can have 0 or more consumers attached to it. If multiple consumers are attached, messages will be load balanced as normal.

The second is called “multicast,” which, as you may have inferred, means that messages delivered to that address will be routed to all queues associated with that address, effectively forming a broadcast topic model. If you are familiar with Virtual Topics in ActiveMQ, it’s notable here that since these queues can also have multiple consumers associated with them, this pattern can be used to create both virtual and traditional topics.

Note the ExpiryQueue queue above, associated with the ExpiryQueue address. This is a default, traditional queue where expired messages will be routed. It has a Routing Type of “ANYCAST,” which effectively makes it a traditional queue.

This differs from the “event” address below it, with a generated client subscription name for a queue, and a Routing Type of “MULTICAST” which means it will behave like a topic.

Persistence Differences

Both Apache ActiveMQ 5 and ActiveMQ Artemis ship with the ability to create persistent messages, which are messages that the broker will write to disk before acknowledging receipt back to producers. This allows the broker to replay these messages should it crash while messages are in-flight and is arguably the most important concept in guaranteed message delivery.

ActiveMQ 5 uses a fast journaling database called KahaDB, where ActiveMQ 6 opts for the persistence journal that was included in HornetQ. Although both are highly performant, KahaDB has some limitations in terms of creating active/passive failover patterns for ActiveMQ 5. This has been overcome with the addition of the JDBC connector for ActiveMQ 5, allowing ActiveMQ 5 to take advantage of traditional RDBMS concepts for its persistence. 

JDBC capabilities are still a work in progress for Artemis, though, it is planned to be fully functional. That said, ActiveMQ Artemis opts for an active-active clustering model anyway, which solves both the problem of horizontal scale and high availability.

HawtIO-Powered

ActiveMQ 5 ships with a Jetty-powered web console that, while functional, is not as feature-rich as the console for Artemis, which is built on top of the powerful HawtIO project:

ActiveMQ Artemis

ActiveMQ 5

Is ActiveMQ Artemis Production-Ready?

The short answer here is yes, with some caveats.

Artemis began its life with the very important advantage that it is built upon two battle-hardened messaging technologies. The challenge of the development community was really to adapt HornetQ’s distinct features to ActiveMQ’s integration, feature, and connectivity model.

In other words, the developers need to ensure that client applications wouldn’t know the difference between ActiveMQ 5 and ActiveMQ 6. That has certainly been achieved, and even improved, with Artemis allowing multiple protocols to exist on a single TCP channel, and backporting those connectors to ActiveMQ’s port readout:

2020-11-13 09:27:47,123 INFO  [org.apache.activemq.artemis.core.server] AMQ221020: Started KQUEUE Acceptor at 0.0.0.0:61616 for protocols [CORE,MQTT,AMQP,STOMP,HORNETQ,OPENWIRE]
2020-11-13 09:27:47,135 INFO  [org.apache.activemq.artemis.core.server] AMQ221020: Started KQUEUE Acceptor at 0.0.0.0:5445 for protocols [HORNETQ,STOMP]
2020-11-13 09:27:47,142 INFO  [org.apache.activemq.artemis.core.server] AMQ221020: Started KQUEUE Acceptor at 0.0.0.0:5672 for protocols [AMQP]
2020-11-13 09:27:47,150 INFO  [org.apache.activemq.artemis.core.server] AMQ221020: Started KQUEUE Acceptor at 0.0.0.0:1883 for protocols [MQTT]
2020-11-13 09:27:47,159 INFO  [org.apache.activemq.artemis.core.server] AMQ221020: Started KQUEUE Acceptor at 0.0.0.0:61613 for protocols [STOMP]

That said, you’ll still find some gaps, such as a still-WIP JDBC adapter, and the absence of the EIP and normalization functionality that was provided by ActiveMQ’s inclusion of Camel Core.

Final Thoughts

For those considering ActiveMQ Artemis, it's worth considering the functionality you use with ActiveMQ 5 and ensure that it has been properly mapped to ActiveMQ 6. If not, ActiveMQ 5 is still in active development, with no planned EOL date as of the writing of this blog, so it might be best to allow ActiveMQ Artemis to fully catch up, feature-wise, to ActiveMQ 5.

Get Guidance, Support, and Training for ActiveMQ

Whether you're considering or actively working with ActiveMQ, OpenLogic architects can provide expert guidance, support, and training to help you accomplish your goals.

Get Guidance and Support  Get On-Demand Training

Additional Resources

Looking for additional resources regarding messaging solutions like ActiveMQ? Be sure to spend some time with these resources.

• Blog - ActiveMQ Use Cases
• Blog - Should You Be Paying for Middleware Tools?
• Webinar - ActiveMQ Applied
• White Paper - Guide to Enterprise Messaging