views:

20574

answers:

17

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.

+1  A: 

There is some discussion in the comments of this blog post, about Twitter writing their own message queue, which may be interesting.

Steve did extensive load and stress testing of ActiveMQ, RabbitMQ, etc. ActiveMQ is actually quite slow (much slower than Kestrel), RabbitMQ consistently crashes with too many producers and too few consumers.

You probably won't have Twitter-like load initially however :)

crb
With the latest version of RabbitMQ (2.0+) a persister has been included, which moves messages out of memory in the above case, This has solved the problem of RabbitMQ crashing with too many producers and too few consumers.
sheki
+19  A: 

More information than you would want to know:

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

FlySwat
I think these guys are thinking about queues wrong--queues shouldn't be 1 (or more) per user. They should be putting their work in a _few_ queues and then utilizing. _inboxes_ (or mboxes) for each user.
Michael Deardeuff
Michael -- want to elaborate a little more? The problem is real-time delivery in a group chat based system. If I'm understanding correctly, you're talking about a durable storage mechanism for messages as an endpoint (inbox)? If so, then it doesn't fit the bill, they want chat to be delivered immediately, and clients to be direct subscribers? As far as I can tell having a ton of topic based queues is not an optimized use case?
Josh
+2  A: 

Abie, it all comes down to your use case. Rather than relying on someone else's account of their use case, feel free to post your use case to the rabbitmq-discuss list. Asking on twitter will get you some responses too. Best wishes, alexis

+5  A: 

There's a comparison between RabbitMQ and ActiveMQ here. Out of the box, ActiveMQ is configured to guarantee message delivery - which can give the impression its slow compared to less reliable messaging systems. You can always change the configuration for performance if you wish and get at least as good performance as any other messaging system. At least you have that option. There's a lot of information on the forums and the ActiveMQ FAQ for configuration for scaling, performance and high availability. Also, ActiveMQ will support AMQP 1.0 when the spec is finalized, together with other wire formats, like STOMP.

Another plus for ActiveMQ is its an Apache project, so there is diversity in the developer community - and its not tied to one company.

Rob Davies
+2  A: 

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 ( Failover 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 ocassions 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 it's issues are not afraid to activly get involved when using .NET develop in java ;-)

Noctris
+12  A: 

These 3 products have differents approaches regarding the implementation of AMQP.

ActiveMQ is not a first-class implementation. According to their website : "ActiveMQ has code in the sandbox for implementing AMQP on ActiveMQ. However, the development of this code has been paused until there is further user and developer interest.". Therefore I wouldn't recomment using it.

ZeroMQ is a bit special because it supports more typologies than what's defined in the AMQP specification. See : http://www.zeromq.org/whitepapers:brokerless. A brokerless typology is particularly interesting for minimum latency and maximum performances.

RabbitMQ is of all 3 the closest to the AMQP specification and it's probably the most used implementation available. It's based on Erlang/OTP which gives a very good scalability.

Finally, you should also look at QPID, an implementation by the Apache Foundation which is supported by Red Hat and Microsoft, and OpenAMQ which I believe is used by JP Morgan.

Julien
While true, I am not sure if adoption of AMQP has strong correlation with the original question. I would think there are more important considerations for one's choice of a message queue than what underlying wire protocol it uses.
StaxMan
+2  A: 

About ZeroMQ aka 0MQ, as you might already know, it's the one that will get you the most messages per seconds (they were about 4 millions per sec on their ref server last time I checked), but as you might also already know, the documentation is non existent. You will have a hard time finding how to start the server(s), let alone how to use them. I guess that's partly why no one contributed about 0MQ yet.

Have fun!

Charle
There are examples in the cookbook http://www.zeromq.org/docs:cookbook and there is a manual http://api.zeromq.org/zmq.html.
Nick
while zmq is fast and have an easy api, keep in mind this: no persistence, no transactions. No detection of falied or slow consumers (messages simply get dropped without any notification to the producer program). Sidenote: zmq is serverless, so you won't find docs for starting the servers. They do have a proxy server if you have need for something like that though.
nos
+1  A: 

We did an evaluation of high performance messaging approaches.

BoostASIO (sockets), ZeroMQ (lightweight messaging framework, and OpenDDS (fully featured implementation of the OMG DDS spec.)

All are open source.

The results are posted in paper with some ease of use comments: http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201004.html

The results are somewhat counter intuitive.

regards Malcolm Spence Director of Bus Dev. OCI St Louis MO USA www.ociweb.com TE:1-314-90-0206

malcolm Spence
A: 

Few applications have as many tuning configurations as ActiveMQ. Some features that make ActiveMQ stand out are:

Configurable Prefetch size. Configurable threading. Configurable failover. Configurable administrative notification to producers. ... details at:

http://activemq.net/blog http://activemq.apache.org

cobrien
+1  A: 

If you are also interested in commercial implementations, you should take a look at Nirvana from my-channels.

Nirvana is used heavily within the Financial Services industry for large scale low-latency trading and price distribution platforms.

There is support for a wide range of client programming languages across the enterprise, web and mobile domains.

The clustering capabilities are extremely advanced and worth a look if transparent HA or load balancing is important for you.

Nirvana is free to download for development purposes.

eddie mcdaid
+2  A: 

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.

Nick
A: 

ZeroMQ is really with zero queues! It is a really mistake! It does not hav queues, topics, persistence, nothing! It is only a middleware for sockets API. If it is what you are looking cool! otherwise forget it! it is not like activeMQ or rabbitmq.

Angek
+1  A: 

There is a comparison of the features and performance of RabbitMQ ActiveMQ and QPID given at
http://bhavin.directi.com/rabbitmq-vs-apache-activemq-vs-apache-qpid/

Personally I have tried all the above three. RabbitMQ is the best performance wise according to me, but it does not have failover and recovery options. ActiveMQ has the most features, but is slower.

sheki
+2  A: 

I have not used ActiveMQ or RabbitMQ but have used ZeroMQ. The big difference as I see it between ZeroMQ and ActiveMQ etc. is that 0MQ is brokerless and does not have built in reliabilty for message delivery. If you are looking for an easy to use messaging API supporting many messaging patterns,transports, platforms and language bindings then 0MQ is definitely worth a look. If you are looking for a full blown messaging platform then 0MQ may not fit the bill.

See www.zeromq.org/docs:cookbook for plenty examples of how 0MQ can be used.

I an successfully using 0MQ for message passing in an electricity usage monitoring application (see http://rwscott.co.uk/2010/06/14/currentcost-envi-cc128-part-1/)

Bob Scott
A: 

what about stormmq? why it is not too much talked? i have searched but seems that are no comments... strange.... anyone have used it?

thanks

kahil
+1  A: 

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.

ron
A: 

Any comments on RestMQ?

Tom