<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 23, 2014 at 4:26 PM, Youngkin, Rich <span dir="ltr"><<a href="mailto:richard.youngkin@pearson.com" target="_blank">richard.youngkin@pearson.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I may have missed it, but in Jesper's reply I didn't see the persistence requirement addressed.</blockquote></div>

<br>One way to approach persistence is to have each process track its state on disk whenever it is sure its state is consistent. The trick is to keep the amount of persist-calls low so most of the way forward moves on volatile messages which are fast. In the event of a crash you reset to the last known stable point and continue on from there.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">For smaller systems, tracking state in mnesia is an obvious candidate. For larger systems, you can use something like Riak.</div><div class="gmail_extra"><br></div>

<div class="gmail_extra">RabbitMQ implements its own persistence layer and just makes sure that data are sync'ed to disk before it accepts the message from the client. In the event of an error, RabbitMQ can then reconstruct its queue state from the disk log. This is one of the reasons never-persisted messages are much faster in RabbitMQ than messages you persist on disk.<br>

<br clear="all"><div><br></div>-- <br>J.
</div></div>