Consumer Flow Limits

When the number of payload messages delivered to the client runtime
exceeds the value of imqConsumerFlowLimit for any consumer,
message delivery for that consumer stops. It is resumed only when the number
of unconsumed messages for that consumer drops below the value set with imqConsumerFlowThreshold.

The following example illustrates the use of these limits: consider
the default settings for topic consumers:

imqConsumerFlowLimit=1000
imqConsumerFlowThreshold=50

When the consumer is created, the broker delivers an initial batch of
1000 messages (providing they exist) to this consumer without pausing. After
sending 1000 messages, the broker stops delivery until the client runtime
asks for more messages. The client runtime holds these messages until the
application processes them. The client runtime then allows the application
to consume at least 50% (imqConsumerFlowThreshold ) of
the message buffer capacity (i.e. 500 messages) before asking the broker to
send the next batch.

In the same situation, if the threshold were 10%, the client runtime
would wait for the application to consume at least 900 messages before asking
for the next batch.

The next batch size is calculated as follows:

imqConsumerFlowLimit - (current number of pending msgs in buffer)

So if imqConsumerFlowThreshold is 50%, the next batch
size can fluctuate between 500 and 1000, depending on how fast the application
can process the messages.

If the imqConsumerFlowThreshold is set too high (close
to 100%), the broker will tend to send smaller batches, which can lower message
throughput. If the value is set too low (close to 0%), the client may be able
to finish processing the remaining buffered messages before the broker delivers
the next set, again degrading message throughput. Generally speaking, unless
you have specific performance or reliability concerns, you will not need to
change the default value of imqConsumerFlowThreshold attribute.

The consumer-based flow controls (in particular, imqConsumerFlowLimit ) are the best way to manage memory in the client runtime. Generally,
depending on the client application, you know the number of consumers you
need to support on any connection, the size of the messages, and the total
amount of memory that is available to the client runtime.