These corner cases are relatively rare, I would think (I personally keep logs around for days or longer).
Would it be possible to get a partial solution in place that invokes the current behavior if logs aren't available? On Wed, Oct 20, 2010 at 10:42 AM, Patrick Hunt <phu...@gmail.com> wrote: > Hi Ted, Mahadev is in the best position to comment (he looked at it last) > but iirc when we started looking into implementing this we immediately ran > into so big questions. One was what to do if the logs had been cleaned up > and the individual transactions no longer available. This could be overcome > by changes wrt cleanup, log rotation, etc... There was another more > bulletproof option, essentially to keep all the changes in memory that > might > be necessary to implement 22, however this might mean a significant > increase > in mem requirements and general bookkeeping. It turned out (again correct > me > if I'm wrong) that more thought was going to be necessary, esp around > ensuring correct operation in any/all special cases. > > Patrick > > On Wed, Oct 13, 2010 at 12:49 PM, Ted Dunning <ted.dunn...@gmail.com> > wrote: > > > Patrick, > > > > What are these hurdles? The last comment on ZK-22 was last winter. Back > > then, it didn't sound like > > it was going to be that hard. > > > > On Wed, Oct 13, 2010 at 12:08 PM, Patrick Hunt <ph...@apache.org> wrote: > > > > > 22 would help with this issue > > > https://issues.apache.org/jira/browse/ZOOKEEPER-22 > > > however there are some real hurdles to implementing 22 successfully. > > > > > >
