[rabbitmq-discuss] TCP Backpressure / Flow Control in C# producer

Matthias Radestock matthias at rabbitmq.com
Wed Aug 8 10:49:42 BST 2012


On 08/08/12 10:29, Ulli Berthold - Exactag GmbH wrote:
> we're running rabbit 2.8.4 / 2.8.5 on 64bit linux servers with 64bit
> erlang and plenty of memory, and there was no "high watermark"
> warning in the logs either. Just to make sure i'm not erring to much
> - if the rabbit web ui shows a connection as "flow" instead of
> "running" or "blocked" that does mean it is in flow control
> (backpressure), correct?

Correct, but as noted at 
http://www.rabbitmq.com/memory.html#per-connection, this kind of flow 
control is triggered many times a second.

It's really not something an application should need to worry about. And 
it does *not* mean the producer is blocked, since there are many buffers 
between the application and the broker connection handler that need to 
fill up first. That way spikes can be absorbed.

Obviously if producers attempt to publish at a *sustained* rate that is 
higher than the broker can handle then backpressure will propagate to 
the client and slow them down. The point at which that happens should be 
way higher than the 3kHz rate you anticipate.


More information about the rabbitmq-discuss mailing list