Which embedded messaging system -> ActiveMQ or HornetQ

Question

I would appreciate some general pointers and opinions regarding which of the two messaging systems is

• easier to manage
• has less gotchas or magic stuff one needs to know and avoid
• has less overal dependencies
• is simple to work with.

Solution 1

easier to manage

hornetQ has a clear API for management and it's very easy to use.

has less gotchas or magic stuff one needs to know and avoid

hornetQ was made for the embedded case. It is very, very easy to integrate it in your code. As a matter of fact you can do it with less than 10 lines of code.

has less overall dependencies

Everything on HornetQ is modular. The only required dependency on HornetQ is Netty which is the network provider.

is simple to work with.

HornetQ is very simple to use. Clear API, and mainly, the documentation is very, very complete.

You don't need to buy any books to use HornetQ. All the docs are right there for free at the hornetq's website.

Solution 2

I use ActiveMq quite heavily in my day job, and rate it very highly for most of the points you raised. I especially rely in the JMX admin console, it's top class.

I have also been keeping a close eye on HornetQ, and may one day add support for that too. From what I can see HornetQ is a bit lighter weight, and has some really nice NIO optimisations, which should make it fly. But lacks some of the enterprise integration features offered by ActiveMQ, and possibly some of the admin features. However, from what I can see the HornetQ team is working hard to fill in the gaps.

I don't think you could do wrong with either choice in my opinion. Try them both out and see which feels better.

Solution 3

I did an extensive evaluation of both before deciding on ActiveMQ. It is proven and stable, something that you want in a messaging system. I have used ActiveMQ on two large scale systems with great success. There was some hype around HornetQ a while back when they claimed to be faster than ActiveMQ so I took a look. HornetQ has some serious flaws with it's clustering which can result in messages being lost and servers trying to indefinitely connect to a failed node. The lead developer on HornetQ refuses to recognize flaws in HornetQ and gets quite defensive on the user forums, something that should make you very wary of the product.

Solution 4

Apache ActiveMQ Artemis is the way to go

The HornetQ codebase was donated to the Apache ActiveMQ project, and the HornetQ community joined that project to enhance the donated codebase and create a next-generation messaging broker. The result is Apache ActiveMQ Artemis.

View more solutions

Comments

[mP.]

One thing i disliked when looking at ActiveMQ is its dependency on Spring ( correct me if im wrong). Suck in Spring and before you know it you have lots of dependencies. HornetQ only requires netty and slf4j. I cant comment about its more exciting features but analysing dependencies is always a good start imho - where less is better.

[mP.]

Thanks Clebert for the answer and for your hard work on HQ! I forgot about my question but your notes are right. Themore one gets into HQ the more one appreciates how kool it is.

[Clebert Suconic]

Regarding your point on ("HornetQ refuses to recognize flaws in HornetQ and gets quite defensive on the user forums, something that should make you very wary of the product.") I don't think that's the case. If it was, it isn't any longer. I'm currently the lead on HornetQ, and We have done a few refactoring on HornetQ 2.2.2 and 2.2.5, and we are doing a few extra great improvements on 2.3.0, and we would love any feedback

[omnomnom]

I've tried both HornetQ and ActiveMQ as a JMS broker for our application which generates very high load. HornetQ wins in performance and reliability. Unfortunately both projects has lacks in documentation. For example, setting cluster of HornetQ machines was a nightmare for me :(

[raffian]

Did you use AMQ embedded or remote broker?

[will]

I agree. I feel it is much better when extras can be orthogonal and optional to a tool. Not always possible, however low-level tools like DB-s, MQ-s, TM-s and the like need not be tightly coupled.