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 vs. Artemis, and considerations for teams who want to use ActiveMQ Artemis in production.

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.

ActiveMQ vs. Artemis 

While ActiveMQ 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. 

While the JDBC capabilities are now considered as “production ready” and no longer in a “work-in-progress” phase in recent releases of Artemis, support for large messages and paging is considerably diminished. 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 the absence of the EIP and normalization functionality that was provided by ActiveMQ’s inclusion of Camel Core, as well as limitations with the JDBC persistence adapter, even though it is no longer considered to be a WIP.

ActiveMQ Artemis Use Cases

In enterprise environments with mature JMS implementations implementing ActiveMQ or other JMS providers, re-architecting to move to Artemis might not make much sense. However, in “greenfield” deployments that do not require the JDBC persistence adapter, selecting Artemis as your JMS provider can make a lot of sense. The following use cases are particularly more suited for an Artemis deployment than other JMS providers.

JMS 2.0 

JMS 2.0 provides a lot of benefits over JMS 1.1; specifically, a more simplified API, shared subscriptions, message delay and priority, and implementing asynchronous messaging as a first-class citizen. Most organizations that have either a small or even no current JMS implementation would most likely want to implement JMS 2.0 instead of the older JMS 1.1 spec. Artemis was developed with the JMS 2.0 specification foremost in mind. To be able to fully leverage JMS 2.0 specification, utilizing a JMS 2.0-compatible provider is required.

Older JMS providers based on the 1.1 spec, such as ActiveMQ, may not fully implement the 2.0 spec. As of its 5.18 release, ActiveMQ has implemented a portion of the 2.0 specification, but is still a work in progress with several portions of the spec slated for future releases. So for now, Artemis is a much better option when it comes to implementing JMS 2.0

Volume and Speed

One of the biggest questions we get at OpenLogic concerning messaging is centered around scaling to support large volumes of messages with high throughput and low latency. Artemis and the JMS 2.0 specifications were developed with this use case in mind. Artemis has shown in some benchmarks to even rival Kafka as far as throughput and latency is concerned. In use cases where these metrics are of high importance, Artemis is a great candidate.

IoT and Realtime Streaming

Given Artemis’s ability to hit throughput benchmarks generally only seen by industry-leading streaming platforms like Kafka, it has become a viable option for IoT devices and real-time streaming. In situations where a JMS provider and a streaming platform is needed to meet one or more use cases, organizations might want to consider Artemis as a single solution instead of having to implement multiple technologies.

Microservices and Event-Driven Architecture

Most messaging providers are perfectly functional and reliable communication channels between distributed microservices. However, given its ability to implement delivery delay and message priority, as well as native asynchronous message consumption in the JMS 2.0 spec, Artemis provides a lot more flexibility in event-driven architecture plans.

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.

Note: This blog was originally published on November 18, 2020 and the content was updated for accuracy in May 2023. 

Get Technical 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. Click on one of the buttons below to learn more!

Get SupportGet Training 

Additional Resources

• Video: Kafka vs. RabbitMQ and ActiveMQ
• Blog - ActiveMQ Use Cases
• Blog - Apache Kafka vs. ActiveMQ
• Blog - Should You Be Paying for Middleware Tools?
• Webinar - ActiveMQ Applied
• White Paper - Decision Maker's Guide to Open Source Middleware