ActiveMQ or RabbitMQ or ZeroMQ or [closed]

Question

We'd be interested to hear any experiences with the pros and cons of ActiveMQ vs RabbitMQ vs ZeroMQ. Information about any other interesting message queues is also welcome.

Answer 1

I'm using zeroMQ. I wanted a simple message passing system and I don't need the complication of a broker. I also don't want a huge Java oriented enterprise system.

If you want a fast, simple system and you need to support multiple languages (I use C and .net) then I'd recommend looking at 0MQ.

Answer 2

I wrote about my initial experience regarding AMQP, Qpid and ZeroMQ here: http://ron.shoutboot.com/2010/09/25/is-ampq-for-you/

My subjective opinion is that AMQP is fine if you really need the persistent messaging facilities and is not too concerned that the broker may be a bottleneck. Also, C++ client is currently missing for AMQP (Qpid didn't win my support; not sure about the ActiveMQ client however), but maybe work in progress. ZeroMQ may be the way otherwise.

Answer 3

Edit: My initial answer had a strong focus on AMQP. I decided to rewrite it to offer a wider view on the topic.

These 3 messaging technologies have different approaches on building distributed systems :

RabbitMQ is one of the leading implementation of the AMQP protocol (along with Apache Qpid). Therefore, it implements a broker architecture, meaning that messages are queued on a central node before being sent to clients. This approach makes RabbitMQ very easy to use and deploy, because advanced scenarios like routing, load balancing or persistent message queuing are supported in just a few lines of code. However, it also makes it less scalable and “slower” because the central node adds latency and message envelopes are quite big.

ZeroMq is a very lightweight messaging system specially designed for high throughput/low latency scenarios like the one you can find in the financial world. Zmq supports many advanced messaging scenarios but contrary to RabbitMQ, you’ll have to implement most of them yourself by combining various pieces of the framework (e.g : sockets and devices). Zmq is very flexible but you’ll have to study the 80 pages or so of the guide (which I recommend reading for anybody writing distributed system, even if you don’t use Zmq) before being able to do anything more complicated than sending messages between 2 peers.

ActiveMQ is in the middle ground. Like Zmq, it can be deployed with both broker and P2P topologies. Like RabbitMQ, it’s easier to implement advanced scenarios but usually at the cost of raw performance. It’s the Swiss army knife of messaging :-).

Finally, all 3 products:

• have client apis for the most common languages (C++, Java, .Net, Python, Php, Ruby, …)
• have strong documentation
• are actively supported

Answer 4

More information than you would want to know:

http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes

---

UPDATE

Just elaborating what Paul added in comment. The page mentioned above is dead after 2010, so read with a pinch of salt. Lot of stuff has been been changed in 3 years.

Answer 5

It really depends on your use-case.

Comparing 0MQ with ActiveMQ or RabbitMQ is not fair. ActiveMQ and RabbitMQ are Messaging Systems wich require installation and administration. They offer featurewise a lot more than ZeroMQ. They have real persistent Queues, Support for transactions etc.

ZeroMQ is a lightweight message orientated socket implementation. It is also suitable for in-process asynchronous programming. It is possible to run a "Enterprise Messaging System" over ZeroMQ, but you would have to implement a lot on your own.

So:

ActiveMQ, RabbitMQ, Websphere MQ & MSMQ are "Enterprise Message Queues"

ZeroMQ is a message orientated IPC Library.

Answer 6

I can only add my 2 cents about ActiveMQ but since this is one of the most popular:

The language you want to write in might be important. Although ActiveMQ does have a client for most, their C# implementation is far from complete compared to the Java Library.

This means some basic functionality is flaky (fail-over protocol that ... well ... fails in some cases, no redelivery support) and other simply isn't there. Since .NET doesn't seem to be all that important to the project, development is rather slowish and there doesn't seem to be any release plan. Trunk is often broken so if you do consider this, you might want to consider contributing to the project if you want things to go ahead.

Then there is ActiveMQ itself which has a lot of nice features but some very strange issues aswell. We use the Fuse (Progress) version of activemq for stability reasons but even then there are a couple of weird "bugs" that you want to keep in mind:

• Brokers that stop sending messages in some occasions
• Journal Errors making the queue show messages that are not there anymore (they don't get delivered to the consumer but still)
• Priority is still not implemented (is on the Issues list since the start of human kind)
• etc. etc.

All and all, it is a pretty nice product IF you can live with its issues:

A) are not afraid to actively get involved when using .NET
B) develop in java ;-)