[rabbitmq-discuss] Flow detection in the RabbitMQ Java Client in 3.2.0

Thu Oct 24 11:07:15 BST 2013

On 24/10/13 10:52, Michael Klishin wrote:
> On 24 Oct 2013, at 08:32, Héctor Veiga <kecok0 at gmail.com> wrote:
>
>> 't sending the flag so the FlowListener was not working at all.
>
> Flow control is a deprecated feature.

Flow control *using the AMQP method channel.flow* is a deprecated 
feature. Or at least we stopped the server from doing that some time ago 
because it has severe limitations. So FlowListener is only useful when 
talking to ancient RabbitMQ versions or other non-RabbitMQ AMQP servers.

Flow control as a concept is alive and well!

> Instead, recent versions of
> RabbitMQ will block publishers by not reading from the socket until
> all alarms (used RAM, # of file available descriptors, disk space
> available) clear.

Note that we block using TCP backpressure in two different cases:

1) Because some resource (memory / disk / file descriptors) is exhausted

(shows up as "blocked" in red in the management web UI)

2) Because the publisher is publishing faster than some component in the 
server (usually queue(s)) can accept messages.

(shows up as "flow" in yellow in the management web UI)

> Clients are notified about these events as of RabbitMQ 3.2 and only
> if they indicate that they support connection.[un]blocked in
> capabilities.

...but clients are only notified about 1) above, not 2).

Why is that?

Because we expect that in case 1) above we will typically block the 
client for a while (several seconds at the very least) until more 
resources become available. When disk space is exhausted we will block 
until more disk space appears - which could take an arbitrary amount of 
time.

However, in case 2) above we only expect to actually block the client 
for a matter of milliseconds - the client will flick between blocked and 
unblocked many times a second. All the client should see is that it is 
publishing at a slower rate than otherwise it might manage to. It's not 
obvious how to indicate that to the client - we certainly would not want 
to spam it with connection.blocked and connection.unblocked many times 
per second.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, Pivotal