Chip Salzenberg | 21 Aug 2012 08:12
Picon

Per-Connection Flow Control -- The Verdict

In a very large prod environment, we have downgraded to 2.7.1 to
escape the flow control misfeature.  It's just not sane.

We are considering more drastic options going forward.

Please give us a flow control switch to turn off.  We just don't want it.
Simon MacMullen | 21 Aug 2012 12:42
Favicon
Gravatar

Re: Per-Connection Flow Control -- The Verdict

On 21/08/12 07:12, Chip Salzenberg wrote:
> In a very large prod environment, we have downgraded to 2.7.1 to
> escape the flow control misfeature.  It's just not sane.
>
> We are considering more drastic options going forward.
>
> Please give us a flow control switch to turn off.  We just don't want it.

Hi Chip. Please don't think us unresponsive to your concerns, but:

When we last spoke about this, there was some unfortunate prioritisation 
going on in the queue process which led to queues staying empty when 
there were large numbers of consumers combined with a low prefetch 
count. This was fixed in 2.8.3. So for your situation:

2.7.1     -> messages queue up in the channel process in the server
2.8.{012} -> producers frequently block
2.8.3+    -> messages queue up in the queue, where they belong

Did you end up trying 2.8.3 or later? If you had problems with flow 
control on 2.8.3 or later then I am very interested in hearing about 
them - flow control should only come on when you are publishing faster 
than RabbitMQ can really accept messages; to turn it off would lead to 
memory use rapidly reaching for the sky in these scenarios.

So I'm reluctant to provide a switch to turn it off since I'm not 
convinced there are situations where this would be useful. I could be 
convinced, of course, but I haven't yet seen a good reason.

Cheers, Simon
(Continue reading)


Gmane