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
> be necessary to implement 22, however this might mean a significant
> in mem requirements and general bookkeeping. It turned out (again correct
> if I'm wrong) that more thought was going to be necessary, esp around
> ensuring correct operation in any/all special cases.
> On Wed, Oct 13, 2010 at 12:49 PM, Ted Dunning <ted.dunn...@gmail.com>
> > 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.
> > >