[rabbitmq-discuss] RabbitMQ memory management

[Ben Hood]

Eran,

On Thu, Sep 11, 2008 at 7:23 AM, Eran Sandler <eran.sandler at gmail.com> wrote:
> At some point the process that was suppose to read from it wasn't restarted
> and the queue eventually kept on growing.

Yes, that's the point of a message queuing system :-)

> When it reached a certain amount of memory it died because it couldn't
> allocate more memory.
>
> My question is, if no one reads from a persistent queue will rabbitmq simply
> die?

Yes, if the Rabbit eats too many carrots, it will die.

Currently we have not implemented an administrative limit of queue
depths, so basically a queue will grow until the Erlang process cannot
allocate any more heap (if the queue is never drained), but this is
something that we are thinking about. This falls under the category of
broker management, for which there have been a few threads already.
This is on our radar, but due to limited resources, we cannot say when
we will get around to doing this.

This also ties into message expiry, which would be a solution to this
problem, but alas, we haven't implemented the TTL property yet (due to
lack of resource and an ambiguous spec). Message expiry has been
discussed in other threads as well.

This is also an item on our todo list, but we will need to be
convinced to prioritize this.

So where does that leave you now?

You've got 2 options:

1. Set the immediate flag when publishing a message. If this flag is
set, the message will not be queued, if it cannot be delivered to a
consumer, it will be discarded.

2. Cluster Rabbit, so that if an instance dies, you don't loose
complete availability.

HTH,

Ben