This guide covers a back pressure mechanism applied by RabbitMQ nodes to publishing connections in order to avoid runaway memory usage growth. It is necessary because some components in a node can fall behind particularly fast publishers as they have to do significantly more work than publishing clients (e.g. replicate data to N peer nodes or store it on disk).
RabbitMQ will reduce the speed of connections which are publishing too quickly for queues to keep up. No configuration is required.
A flow-controlled connection will show a state of
rabbitmqctl, management UI
and HTTP API responses. This means the connection is experiencing
blocking and unblocking several times a second, in order to keep the rate of
message ingress at one that the rest of the server (e.g. queues those messages are route to)
In general, a connection which is in flow control should not see
any difference from normal running; the
is there to inform the sysadmin that the publishing rate is
restricted, but from the client’s perspective it should just
look like the network bandwidth to the server is lower than it actually is.
Other components than connections can be in the
flow state. Channels, queues and other parts of the system
can apply flow control that eventually propagates back to publishing connections.