[rabbitmq-discuss] rabbitmq-discuss Digest, Vol 18, Issue 34

[Ilya Grigorik]

> This is probably my ignorance, but I'm getting slightly confused about
> what exact cause and effect you are investigating.
>

Ben, I think we're on the same page. I understand the current limitations,
and now I'm trying to figure out the ceiling thresholds for setting up a
production node: memory usage patterns, how it performs when swapping, etc.
Also found a few bugs in the Ruby client, working on addressing those. :)

If you don't use producer flow control (the channel.flow command) to
> throttle message sending, eventually you will run out of resources and
> you will see the behaviour that you are reporting.
>

Yep.

Marking messages as persistent is not going to help with the current
> implementation.
>
> When a message is marked as persistent, it means that there is an
> additional replica of the message on disk. The purpose of the replica
> is to be requeued as part of the queue recovery process, if the
> message was not subsequently ack'ed by a consumer.
>


> ATM Rabbit is not smart enough to piggy back off the journal to smooth
> out memory consumption.
>


> Also, it is questionable as to whether this would be the best way to
> solve the infamous queue paging problem.
>

Yep, good points. I think we'll go ahead an implement our own backup
strategy for time being, but I do hope that we'll see some sane overflow
conditions make it to RabbitMQ sooner rather than later (number of messages,
ttl, whichever).

Cheers,
ig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20081118/2395d07d/attachment.htm