[rabbitmq-discuss] Usefulness of Channel.Flow with RabbitMQ 2.x.x

A. MacLeod allister.macleod at gmail.com
Tue Nov 9 16:43:27 GMT 2010

Hi. I am researching AMQP flow control strategies to use for a
distributed application that uses RabbitMQ for interprocess message
passing.  The "channel.flow" and "channel.flow_ok" messages from the
AMQP spec at first seemed to be a useful first step for flow control.
However, from looking at various documentation, forum posts, and
looking at the RabbitMQ source, it looks like we may not get very much
benefit from channel.flow when we are using RabbitMQ version 2.0.0 or

Am I correct in concluding that a RabbitMQ 2.x.x broker will never
generate a channel.flow message, ever?  I grepped the Erlang source
and saw that the broker responds to incoming channel.flow messages
appropriately.  There is a comment in the memory management code that
mentions that a memory alarm should cause channel.flow, but I did not
see anything in actual code to back that up.

A post from Marek M. in
indicates that channel.flow behavior has changed between 1.8.1 and
2.0.0.  From what I understand, the broker now effects flow control by
just not reading bytes from the socket instead of issuing channel.flow
messages.  This is consistent with a test I ran, using the 2.0.0 Java
client library, where I have a producer thread continuously shove 8kb
messages into a direct exchange, and have a slow-poke consumer using
basic.consume to receive acknowledgement-required messages very
slowly.  Once the memory fills up, the producer visibly slows down,
but FlowListener never has handleFlow called.

I have also tried some experiments where I use something like
consumerChannel.flow(false) to stop flow on the consumer's channel.
However, when I try to reopen the flow by doing
consumerChannel.flow(true), my consumer instance (of a class derived
from DefaultConsumer) never receives any more messages.  Do I need to
re-issue consumerChannel.basicConsume(...) after I re-enable flow from
the consumer side?

Thanks in advance,

More information about the rabbitmq-discuss mailing list