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

[Ben Hood]

Ilya,

On Sun, Nov 16, 2008 at 3:26 PM, Ilya Grigorik <ilya at aiderss.com> wrote:
> Ben, I may be running out of patience on the recovery of the queue (after
> the crash), I'll try overloading it once more later tonight and report on my
> findings.

Is this running 1.4.0 or the latest development version?

> 1. I would love to have control of overflow conditions at at queue level.
> Having said that it's a double edged sword. Once you're that granular it
> also becomes painful do resource planning (woops, forgot a queue) and server
> has gone to hell - though I think it's a fair tradeoff.

Producer flow control (with behaving clients) would prevent the server
going to hell, you just might not have transparent overflow on that
particular queue that you misconfigured.

> 2. I really like the idea of being able to fix the maximum size on a queue,
> as that would allow me to plan for the amount of available memory + disk and
> guarantee some QoS thresholds. Drop, Trip, Warn would be perfect for a hard
> limit, and I imagine TTL could be an interesting solution to anyone working
> with time-sensitive data.

TTLs are on the mid-term radar.


>> Filling up a SAN though can be considered an exceptional and absolutely
>> unavoidable last barrier, after all if you manage to fill up to
>> 500GB of space of an average consumer disk probably you forgot that the
>> server even exists.
>
> Not entirely true, based on my calculations we (AideRSS) would need ~250GB
> of space to buffer a day's worth of messages, and that is something we're
> aiming for. (Though we may be an edge case)

That was Valentino's (I think :-) answer to my question about what to
do when your SAN fills up, which I've seen happen.

Ben