[
https://issues.apache.org/jira/browse/BOOKKEEPER-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13156707#comment-13156707
]
Flavio Junqueira commented on BOOKKEEPER-112:
---------------------------------------------
I'm not sure I have a good way to guarantee that it always happens this way,
but my feeling is that we shouldn't try to recover a bookie that participated
in a ledger ensemble for which the ledger is still open.
One way is to check that all ledger fragments to recover are from ledgers that
have been closed already. We can do it by checking the ledger metadata stored
in zookeeper. Bookie recovery proceeds only if all ledger are closed.
> Bookie Recovery on an open ledger will cause LedgerHandle#close on that
> ledger to fail
> --------------------------------------------------------------------------------------
>
> Key: BOOKKEEPER-112
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-112
> Project: Bookkeeper
> Issue Type: Bug
> Reporter: Flavio Junqueira
> Assignee: Ivan Kelly
> Fix For: 4.0.0
>
>
> Bookie recovery updates the ledger metadata in zookeeper. LedgerHandle will
> not get notified of this update, so it will try to write out its own ledger
> metadata, only to fail with KeeperException.BadVersion. This effectively
> fences all write operations on the LedgerHandle (close and addEntry). close
> will fail for obvious reasons. addEntry will fail once it gets to the failed
> bookie in the schedule, tries to write, fails, selects a new bookie and tries
> to update ledger metadata.
> Update Line 605, testSyncBookieRecoveryToRandomBookiesCheckForDupes(), when
> done
> Also, uncomment addEntry in
> TestFencing#testFencingInteractionWithBookieRecovery()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
