<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;">This is probably my ignorance, but I'm getting slightly confused about<br>
what exact cause and effect you are investigating.<br>
</blockquote><div><br>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. :)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If you don't use producer flow control (the channel.flow command) to<br>
throttle message sending, eventually you will run out of resources and<br>
you will see the behaviour that you are reporting.<br>
</blockquote><div><br>Yep. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Marking messages as persistent is not going to help with the current<br>
implementation.<br>
<br>
When a message is marked as persistent, it means that there is an<br>
additional replica of the message on disk. The purpose of the replica<br>
is to be requeued as part of the queue recovery process, if the<br>
message was not subsequently ack'ed by a consumer.<br></blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
ATM Rabbit is not smart enough to piggy back off the journal to smooth<br>
out memory consumption.<br>
</blockquote><div> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also, it is questionable as to whether this would be the best way to<br>
solve the infamous queue paging problem.<br>
</blockquote><div><br>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). <br>
<br>Cheers,<br>ig<br></div></div><br>