[rabbitmq-discuss] Performance degrades with increasing queue depth

[Aisha Fenton]

Sorry meant to say EventMachine, not libevent.

> I am interested as to what the specific issue is with sending acks
> with libevent - are you saying that the app can issue an ack and this
> can potentially go AWOL between the the libevent API returning and the
> point it time when the AMQP frame is actually written to the socket?


This article sums it up well. I haven't investigated this myself  
though, so only going on a other peoples comments.
http://pivotallabs.com/users/jpalermo/blog/articles/952-rabbitmq-amqp-gem-and-eventmachine

The article also suggests a workaround. Use MQ.prefetch(1)



On 9/09/2009, at 2:01 AM, Chuck Remes wrote:

> Aisha is mistaken. The ruby amqp library does not use libevent  
> anywhere. It uses EventMachine under the covers which is a home- 
> grown reactor written in C that uses select, poll and kqueue  
> depending on the platform.
>
> cr
>
>
> On Sep 8, 2009, at 8:33 AM, Ben Hood wrote:
>
>> Aisha,
>>
>> Not wanting to hijack this thread another time, but....
>>
>> On Mon, Sep 7, 2009 at 10:44 PM, Aisha  
>> Fenton<aisha.fenton at gmail.com> wrote:
>>> The library I'm using (http://github.com/celldee/bunny/tree/ 
>>> master) is
>>> synchronous only. I'm considering switching to (http://github.com/tmm1/amqp/tree/master
>>> ) which is async and uses libevent. However, I've read that there  
>>> are
>>> problems with msg acknowledges in apps that use libevent, because  
>>> the
>>> OS can buffer the ack responses. And although I'm not using ack  
>>> yet, I
>>> want to in my production system.
>>
>> I am interested as to what the specific issue is with sending acks
>> with libevent - are you saying that the app can issue an ack and this
>> can potentially go AWOL between the the libevent API returning and  
>> the
>> point it time when the AMQP frame is actually written to the socket?
>>
>> Ben
>