<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div class="gmail_quote">
<div><br></div><div>Am I missing something ? Loosing data is something I cannot afford ! I Plan to use this store as a *permanent* one... I have no backup ! (Actually S3 is the backup) - So, no, I don't want this ... at any price ;-)</div>
</div></blockquote><div><br></div></div><div>Then set <async enabled="false" /> in your cache store config. :-)</div></div></div></blockquote><div><br></div><div>That is exactly what I planned to do... for the FileCacheStore since the latency is quite low and the failure rate almost zero.</div>
<div>But the S3 store is very slow, and asynchronism is not a luxury...</div><div><br></div><div>Right now, I am trying to make my own custom solution based on the size of the cache in memory (as trigger) and then I will evict specific oldest entries... hoping that async transactions are fully committed.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><br><blockquote type="cite"><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>reduced by looking through the async queue as well, before checking the underlying store. But as I said, this just reduces the size of this window and not eliminate it altogether, since this is async and there is no guarantee that the cache store has finished writing internally (e.g., an fsync() operation or in the case of S3, Amazon's eventual consistency model).</div>
<div><div></div><div><br><div><br></div></div></div><div>Why should eviction be transactional? I don't need eviction to be an all-or-nothing, reversible event. :) If an entry gets evicted, cool. If not (for whatever reason), too bad, move on to the next evictable entry. </div>
</div></div></blockquote><div><br></div><div>You are right, we don't want to rollback evictions... but maybe we should use a priority queue to be sure that evictions are done after any other command ? Doesn't it solve it all ? </div>
<div><br></div><div>1) The eviction thread runs (we could lower the priority of this thread too)</div><div>2) It fills a queue of keys to evict</div><div>3) The async queue is prioritized and evicts entries ... when there is nothing else to do (suddenly it looks like garbage collecting)</div>
</div></blockquote><div><br></div></div><div>That is a possibility. But I don't expect to be making any drastic changes to the existing eviction code anymore. Don't know if you have been following discussions re: LIRS, lock amortization, etc., but Vladimir is working on some very interesting self-evicting, bounded data containers which would mean that the eviction threads, etc all get ripped out.</div>
<div><div></div><div class="h5"><br></div></div></div></div></blockquote></div><br><div>Sounds terrific... </div><div><br></div><div>Just to close the subject, shouldn't the documentation explicitly say that async and eviction are not "compatible" ?</div>
<div><br></div><div>phil</div><div><br></div>