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.<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<a href="https://dev.rabbitmq.com/wiki/DiskOverflow" target="_blank">https://dev.rabbitmq.com/wiki/DiskOverflow</a><br>
<br>
Comment and add suggestions if any.</blockquote></div><br>Lots of great ideas in there, a few things that stood out to me:<br><br>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. <br>
<br>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.<br>
<br>> Filling up a SAN though can be considered an exceptional and absolutely
unavoidable last barrier, after all if you manage to fill up to <br>> 500GB
of space of an average consumer disk probably you forgot that the
server even exists.<br><br>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)<br>
<br>ig<br>