Oftentimes people talk to each other about using ActiveMQ, but they’re actually referring to different brokers. That is because there are 3 different message brokers with ‘ActiveMQ’ in their name and this turns out to be pretty confusing when a project as big as WildFly starts to use a broker with ‘ActiveMQ’ in its name that is not the broker that was known for years under the name ‘ActiveMQ’.
So there are 3 projects:
- ‘ActiveMQ‘, sometimes called ‘ActiveMQ 5’ to highlight the difference to the other projects. This is the main project in its current version 5, which is a field proven broker that is used in multiple commercial projects such as Mule or FUSE. ActiveMQ 5 supports many messaging protocols, different journal storages and also a very nice and flexible configuration.
- ‘ActiveMQ Apollo‘ is a broker that was the designated successor of ActiveMQ 5: ActiveMQ 6. It ‘was built from the original foundations’ (citing Apollo’s website) of ActiveMQ 5 with some radical architecture changes to improve performance, reliability and maintainablity. This project seems to have become dormant since the introduction of the 3rd ActiveMQ project:
- ‘ActiveMQ Artemis‘ is not a fork or a reimplementation but rather started as the HornetQ broker. HornetQ’s code was donated to the ActiveMQ project and is now developed by the developers of HornetQ under the new name ActiveMQ Artemis. So basically it’s a completely different and field proven broker. Artemis is known to be rather fast for a JMS broker. Artemis received and is still receiving a lot of changes to build it up to the feature set of ActiveMQ 5. The last official statement I heard is that Artemis might at some point become the successor of ActiveMQ 5, but that is not decided yet. The Wikipedia article for ActiveMQ is pretty confusing about version 6 at the moment. As soon as this is decided there will be a definitive announcement from the ActiveMQ project itself.
The project I usually think of when I hear ‘ActiveMQ’ is the main project ‘ActiveMQ 5’. However the latest WildFly, as well as RedHat’s EAP 7, distribute ActiveMQ Artemis as their JMS broker. The ‘Artemis’ part often gets left out when talking about it and so I have had quite a few people thinking that WildFly now actually has ActiveMQ 5 in it. We at akquinet also have a JBoss based application that embeds ActiveMQ 5. After looking at the table below and knowing that we need MQTT in that application this totally makes sense.
I explained that Artemis has moved rather quickly in extending its feature set. So there are quite a few distributions out there with different versions and different features, which all have to be compared to the actual ActiveMQ 5 they are often confused with. Have a look at it:
|Artemis standalone||Artemis||1.5||AMQP, STOMP, MQTT, OpenWire, HornetQ Core|
|ActiveMQ 5 standalone||ActiveMQ 5||5.14||AMQP, STOMP, MQTT, OpenWire|
|WildFly 8, 9||HornetQ||2.4||AMQP, STOMP, HornetQ Core|
|JBoss EAP 6.4||HornetQ||2.3||AMQP, STOMP, HornetQ Core|
|WildFly 10||Artemis||1.1||AMQP, STOMP, HornetQ Core|
|JBoss EAP 7||Artemis||1.1||HornetQ Core|
No, the limited protocol support in EAP 7 is not a typo. It reflects that these protocol implementations are fairly young, EAP has always released more conservatively and that RedHat offers alternatives in their product portfolio if you need more protocols. You could probably mod EAP 7 to the feature set of WildFly 10, but without RedHat support of course.
One edge case to consider is about outgoing connections. Brokers do not necessarily support all these protocols when connecting to another broker. Test that out if you have specific needs here.
So what do I suggest using? I think that depends very much on your specific situation. I personally like how flexible ActiveMQ 5 can be, but I also appreciate HornetQ/Artemis for its higher throughput and its discovery options, which you get through JGroups. If you need advice here, just send me an email to immanuel.sims (at) akquinet.de .