[rabbitmq-discuss] Limit QueueingConsumer Memory Usage

Ben Hood 0x6e6562 at gmail.com
Sun Jul 12 22:14:52 BST 2009


On Fri, Jul 10, 2009 at 9:36 PM, Lars George<lars at worldlingo.com> wrote:
> Thanks for the answer. So this QoS is only in trunk of the Java client. I
> will have to check this out.

The QoS command is part of all of the client libraries that the Rabbit
team maintain. I'm reasonably sure that other clients implement this
as well, since the client side is trivial - all of the complexity is
on the server side.

> Using the DefaultConsumer means extending it anyways, right? As by default
> it does not do anything. Even setting QoS to 1 would mean you will have to
> enforce ack'ing the message or else the async process will keep sending the
> next one. So a simple single local Delivery bean instance could hold the
> current message.
> Saves the queue part. But then you also have to lock on that instance for
> the blocking behavior, which the QueueingConsumer has build in.
> Am I on the right track here?

IMHO the QueueingConsumer abstraction is double-edged sword. It is a
really great way to easily consume messages without having to
implement every protocol callback. However, without flow control, the
QueueingConsumer can absorb the pressure that you actually want to
push back onto the broker to stem the flow on messages. This aspect is
irrelevant if you do use flow control, but doing so kind of obviates
the need to have this blocking convenience.



More information about the rabbitmq-discuss mailing list