Potential Out of Memory in `QueueingConsumer`

[jbee]

The QueueingConsumer adds all received messages to the _queue buffer.

When messages are received faster from the channel than someone processes them and thereby removes them from the _queue the _queue will grow and eat heap memory until out of memory occurs.

[michaelklishin]

See #19.

[michaelklishin]

Also, this repository is a mirror. Please post your questions and concerns to rabbitmq-users.

[jbee]

Suppose basic.qos is used to limit messages in the queue. Conversation in #19 is unclear about if that actually works or if there the OOM still occurs under certain circumstances.
If limitation works does this change anything about risk of dropping/losing messages?
It would be nice to not need to go through all the same findings you and others seamed to have made in the past. The goal is clearly to consume messages at the rate the consumer is able to handle them and have messages coming in faster pile up in rabbit's queue (not in the in memory queue).

[michaelklishin]

@jbee the very last comment in #19 suggests the client now runs into TCP backpressure if consumers are slow and can't keep up.

QueueingConsumer is just one of the possible consumer implementations. Use a different one (e.g. subclass DefaultConsumer) if you still have concerns.

[michaelklishin]

basic.qos limits the max number of messages delivered to a client before an acknowledgement arrives ("messages in flight" or "in processing"). Which sounds exactly like what you are asking for, regardless of whether the client also uses TCP backpressure.