> WC got a normal I/O, entering ensemble change logic. But it could not do > ensemble change, since ledger state is already changed from OPEN to > IN_RECOVERY. so it would fail. If it doesn't stop and fail, it is a bug for > fencing, right? Please keep in mind, fencing is guarantee by bother > metadata CAS and fence state in bookie servers. We changed the metadata > before proceeding any actions. It would guarantee one is succeed and the > other one is failed. Ah, so the write I was referring to is actually the one write that you propose keeping? I think that could work then.
I would define it as BookKeeper#resumeLedger(int ledgerId, DigestType type, byte[] passwd) though. Overloading openLedger is a bit ugly. Also, I don't think the shrink operation is necessary. The aim here is to avoid the metadata spike, yes? If so, we can still roll the ledger when it gets to a certain capacity, and this is unlikely to happen on a spike. Not having the shrink operation will also help preserve the "immutable after close" property that ledgers have. -Ivan
