On 12/14/06, Marc Herbert <[EMAIL PROTECTED]> wrote:
Emmanuel Cecchet <[EMAIL PROTECTED]> writes:
> If we allow the recovery log to be an optional element, that forces us
> to clutter the code with 'if (recoveryLog!=null)' all over the
> places. This often leads to NPE in the cases we missed
The natural and safe solution to this kind of issue is to implement a
fake recovery log. Niraj do you think you could contribute this?
I like the idea of a fake recovery log. Would the general idea be to
just throw away any data sent to it? While I haven't looked at the
recoverylog code in detail, this just seems to be a matter of creating
a subclass (or an interface) for
controller.recoverylog.RecoveryLog.java and modifying both the DTD and
controller.recoverlog.DatabasesParser.java to allow a null log to be
specified.
I can look into creating a patch sometime early in January.
Niraj
Niraj
> not having a recovery log does not allow to add new nodes or
> recovery from failures (which is really what Sequoia has been
> designed for).
Wasn't it also designed for load-balancing? Raidb0 does not look like
it is able to recover from failures, does it?
_______________________________________________
Sequoia mailing list
Sequoia@lists.forge.continuent.org
https://forge.continuent.org/mailman/listinfo/sequoia
--
http://www.cs.cmu.edu/~ntolia
_______________________________________________
Sequoia mailing list
Sequoia@lists.forge.continuent.org
https://forge.continuent.org/mailman/listinfo/sequoia
