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

Sat Aug 29 22:00:34 BST 2009

RMQ is definitely not hype ware. If you Google around on ActiveMQ  
you'll find more than a few horror stories of AMQ dropping messages  
regularly. That's what drove us to find something else...that  
something ended up bring Rabbit.

Also, if you have to queue to disk to keep from keeling over, there's  
something very inappropriate about the sizing of your setup. Not to  
say disk queuing doesn't have a place, but if you're so overloaded  
that it's required you're not that long from AMQ seizing up too due to  
inability to service requests because of disk latency.

Just my two cents.

-J

Sent via iPhone

On Aug 29, 2009, at 11:19, Alexis Richardson <alexis.richardson at gmail.com 
 > wrote:

> Hi
>
> Thanks everyone for these emails.
>
> To further Ben's excellent response, if anyone has any use cases or
> tests where they are not seeing what they expect, please do let us
> know as much as you can about what you are seeing.  If you can post
> any test harnesses on the web, eg on github, then everyone can try to
> replicate what you are seeing.  In the case of a messaging system like
> RabbitMQ or ActiveMQ, the most interesting production behaviours may
> take time to observe so *any* concrete tests to replicate unusual
> behaviour are *very* helpful.
>
> Cheers,
>
> alexis
>
>
>
>
> On Sat, Aug 29, 2009 at 8:26 AM, Gavin M. Roy<gmr at myyearbook.com>  
> wrote:
>> While I've not completed my migration from ActiveMQ to RabbitMQ,  
>> every
>> indication is that it is faster in my work load.  I do not have
>> thousands of consumers, but I do have thousands of clients  
>> connecting,
>> enqueueing and disconnecting.
>>
>> In this scenario, connection times in ActiveMQ increase over the
>> course of days, starting at 4ms and if left unattended to, increase
>> to100's of ms.  The only way to resolve this is to restart the
>> ActiveMQ broker which is disruptive and an operational issue for us.
>>
>> In addition, load tests show that ActiveMQ slows considerably with
>> steady enqueue with no dequeue, over the course of 1000's of  
>> messages.
>>  I ran this same test with RabbitMQ runs steady until it runs out of
>> memory which for my tests was around 2M messages.
>>
>> Regards,
>>
>> Gavin
>>
>> On Sat, Aug 29, 2009 at 10:20 AM, Dikkie Hagel<dikkiehagel at hotmail.com 
>> > 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
>>>
>>>
>>
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss