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

[Ilya Grigorik]

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.

https://dev.rabbitmq.com/wiki/DiskOverflow
>
> Comment and add suggestions if any.


Lots of great ideas in there, a few things that stood out to me:

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.

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.

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

ig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20081116/e4ff3b11/attachment.htm