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

[Ulli Berthold - Exactag GmbH]

Hi Matthias,

well, it does happen here... There are times when our queues grow to a couple of million messages (which actually was not a problem in 2.7.1), in 2.8.4 it went into flow control mode when the CPU load got higher though not limiting out.

Our problem is that we constantly produce lots of messages which have to be forwarded within milliseconds or we will run into frontend delays which should not occur.
I'm looking for a way to keep the queueing server accepting messages at the highest possible rate no matter what, for as long as it's not "full" (memory, disk, cpu). There is no real way for us to limit the input. And we know that the consumers will clear out the queues sooner or later, just not in real time.

And when we finally reach a point where the server is almost full, I'd curious if the flow control events of the C# driver will ever be fired? As I said, that would enable us to use a file-based fallback that's mostly intended for queuing server downtimes.

channel = connection.CreateModel();
    channel.ChannelFlow(true);
    channel.FlowControl += new RabbitMQ.Client.Events.FlowControlEventHandler(channel_FlowControl);

Regards from Germany

Ulli

-----Ursprüngliche Nachricht-----
Von: Matthias Radestock [mailto:matthias at rabbitmq.com] 
Gesendet: Mittwoch, 8. August 2012 11:50
An: Ulli Berthold - Exactag GmbH
Cc: Discussions about RabbitMQ
Betreff: Re: AW: AW: AW: AW: [rabbitmq-discuss] TCP Backpressure / Flow Control in C# producer

Ulli,

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.

Matthias.