[rabbitmq-discuss] rabbitmq-discuss Digest, Vol 18, Issue 34
ilya at aiderss.com
Sun Nov 16 15:26:32 GMT 2008
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
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss