[rabbitmq-discuss] RabbitMQ memory management

[Eran Sandler]

I think. Thanks for the lengthy reply :-)


Since its open source I might be able to invest some time for things 
that will be relevant for us and I would probably benefit from learning 
Erlang more intimately as well as from your experience :-)


Regarding clustering, I have a question about that.

Configuring the clustering on the rabbitmq side is easy, but how it all 
translates on the client side?


Does the .NET client (or any other client for that matter) supports 
flipping between nodes on a cluster automagically or is it something 
that I need define by myself and tell it to connect to a different node 
in a cluster?


Eran


Ben Hood wrote:

> 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
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080911/8bcd66a3/attachment.htm