Abstract
Flow control ensures that the rate at which messages are transmitted from the publisher to the receiver is controlled. Back-pressure is exerted when the defined global memory threshold or message count threshold per connection is exceeded. At this point, message acceptance is blocked until the sender is notified of memory recovery. In the meantime, a background process constantly checks whether the memory is recovered, and when the memory is available the sender is notified and can resume sending messages to the server. Flow control configurations are defined in the <MB_HOME>/repository/conf/advanced/andes-config.xml
file.
Introduction
“Flow control” can generally be identified as a technique that is typically employed in controlling fast producers from overloading slow consumers, in producer-consumer scenarios.
There exists quite a few cases that might lead to fast producer - slow consumer scenarios. For example, if we consider an instance where the consumer is incapable of handling the rate of messages being produced due to various reasons such as, being on low resource footprint, etc, there could be a definite chance that the Message Broker, which lies in the middle of the producer and the consumer, gets overloaded at a particular moment as a result of message accumulation within the Broker itself. This can cause Message Broker instances to run out of resources such as memory, etc. Therefore, it’s required to have a mechanism in place which would prevent the fast publishers from overwhelming the Message Broker, in the presence of slow consumers as well as in many other scenarios if exerted, would overload the Message Broker.
Implementation
WSO2 Message Broker, primarily supports memory-based flow controlling. There, it allows users to configure a Message Broker Server instance with two parameters namely, “globalMemoryTreshold” (defaults to 0.4) and “globalMemoryRecoveryThreshold” (defaults to 0.5) corresponding to the “memory threshold at which flow controlling is enabled” as well as the “memory threshold at which flow controlling is disabled and the resumption of message publishing would take place”, respectively. All publishers are notified and blocked temporarily when flow controlling is activated till they are notified back when the memory levels are recovered in MB. In an event where a message could not be published within a configurable amount of time declared by the system property “qpid.flow_control_wait_failure” (defaults to 120s) at the client-end, the client would terminate the connection that it has established with the server for the task of message publishing and an error is thrown. Further, the system property named “qpid.flow_control_wait_notify_period” (defaults to 5s) can effectively be used to print a log message periodically after the configured amount of time.