[
https://issues.apache.org/jira/browse/BOOKKEEPER-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13150526#comment-13150526
]
[email protected] commented on BOOKKEEPER-106:
----------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2806/
-----------------------------------------------------------
(Updated 2011-11-15 14:40:58.957071)
Review request for bookkeeper.
Summary (updated)
-------
As the summary says, if you don't specify a destBookie when doing
recoveryBookieData, it will select at random from the available bookie list. It
doesn't take care to select a bookie which is not is the ledgers ensemble.
A new bookie is now selected for each bookie & ledger metadata is now updated
once each fragment has been replicated. There is a new algorithm for selecting
the new bookie, which takes into account the current bookies.
The structure of the callbacks needed to be changed to allow an update for each
individual fragment. Now when you recover a bookie, the recovery callback is
wrapped a multi callback (MCB-LEDGERS) is created with a count equal to the
number of ledgers which will be recovered. MCB-LEDGERS is passed to call to
#recoverLedger for each ledger. #recoverLedger creates a multi callback
(MCB-FRAGMENTS), with the number of fragments to be recovered as the count.
Then a loop kicks off recovery for each fragment, passing a new
SingleFragmentCallback to each. SingleFragmentCallback takes MCB-FRAGMENTS as a
parameter, and triggers it each time a fragment recovery completes.
SingleFragmentCallback and the fragment count multi callback, replace
ledgerFragmentMcb, which wrapped LedgerMultiCallbackWrapper, which in turn
wrapped MCB-LEDGERS. LedgerMultiCallbackWrapper updated the ledger metadata
once during the recovery process, when the whole ledger was recovered, but only
specified a single possible ledger. This was incorrect as it could lead to
underreplication. The new approach, writes once per fragment. The callback
restructuring was necessary to allow this.
I've also added a couple of tests and some test framework stuff to verify that
entries are all replicated.
This addresses bug BOOKKEEPER-106.
https://issues.apache.org/jira/browse/BOOKKEEPER-106
Diffs
-----
bookkeeper-server/src/main/java/org/apache/bookkeeper/client/BookKeeperAdmin.java
b3eb5b9
bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieServer.java
f1b3ad9
bookkeeper-server/src/test/java/org/apache/bookkeeper/client/BookieRecoveryTest.java
PRE-CREATION
bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BaseTestCase.java
6bac569
bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieRecoveryTest.java
ac54d9a
Diff: https://reviews.apache.org/r/2806/diff
Testing
-------
Thanks,
Ivan
> recoveryBookieData can select a recovery bookie which is already in the
> ledgers ensemble
> ----------------------------------------------------------------------------------------
>
> Key: BOOKKEEPER-106
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-106
> Project: Bookkeeper
> Issue Type: Bug
> Reporter: Ivan Kelly
> Assignee: Ivan Kelly
> Priority: Blocker
> Fix For: 4.0.0
>
> Attachments: BOOKKEEPER-106.diff
>
>
> As the summary says, if you don't specify a destBookie when doing
> recoveryBookieData, it will select at random from the available bookie list.
> It doesn't take care to select a bookie which is not is the ledgers ensemble.
--
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
