[rabbitmq-discuss] Is RabbitMQ indeed "hype ware"?

Michael Arnoldus chime at mu.dk
Sat Aug 29 16:11:22 BST 2009


For what it's worth I've been using RabbitMQ in a production system  
running 24/7 for more than 2 year, running flawlessly. I wouldn't  
hesitate to use it again.

Whether it will solve your specific issues or not, I can't tell.

Also, I believe in the AMQP standard effort as I feel less "locked in"  
than with other solutions.

YMMV.

Regards,

Michael Arnoldus

On Aug 29, 2009, at 16:20 , Dikkie Hagel wrote:

> Hello,
>
> I am in the process of setting up messaging middleware for a  
> webbased platform which should be able to handle millions producers/ 
> consumers.
>
> We've started our development with ActiveMQ. Everything seemed to  
> work fine until we started connecting with 1000 consumers to a  
> single topic. ActiveMQ could not handle this at all, complaining  
> about "too many open filehandles". Others seem to have encountered  
> this same issue as well (see second life's review), but we've not  
> been able to google a solution. That was a major showstopper, and  
> made us conclude that something was terribly wrong with the  
> architecture of this software, which made it unsuitable for our  
> intended purpose.
>
> We then turned to RabbitMQ, and after fixing the Perl and  
> ActionScript AMQP interfaces (http://github.com/joodie) we now  
> almost have a working prototype for our environment, ready for some  
> first performance tests.
>
> Now I just received a mail from the ActiveMQ/Fuse support team,  
> which in reply to my report to them about the 1000 consumers issue,  
> quotes their "Manager Engineering", stating the following:
>
> ============== START OF QUOTE =================
> This is due to the configuration out of the box for ActiveMQ - its  
> very
> straightforward for ActiveMQ to handle the same load as RabbitMQ.
> There are some significant benefits in using ActiveMQ over RabbitMQ.
> ActiveMQ has no limit on the depth (number of messages) in a Queue -
> other than disk space. RabbitMQ runs out of memory.
> Also - there's performance benefits too - although sending messages  
> can
> be a lot faster to RabbitMQ (this is due to RabbitMQ caching  
> messages in
> memory) - consuming messages is considerably slower.
> In reality, RabbitMQ is just hype ware - not really suitable for
> production scenarios. Although its getting a lot of traction, it only
> suitable for cases where consumers will always keep up with producers.
> =============== END OF QUOTE ======================
>
> Now that's a pretty scary assesment there. "Hype ware"... Perhaps  
> RabbitMQ's engineers can reply to this, and reassure us that our  
> shift in favour of RabbitMQ is a sound decision? (we plan to deploy  
> it on systems with plenty gigs of RAM).
>
> Kind regards, Roberto
> What can you do with the new Windows Live? Find  
> out_______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090829/8bfa1e04/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1912 bytes
Desc: not available
Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090829/8bfa1e04/attachment.bin 


More information about the rabbitmq-discuss mailing list