[
https://issues.apache.org/jira/browse/BOOKKEEPER-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Kelly updated BOOKKEEPER-106:
----------------------------------
Attachment: BOOKKEEPER-106.diff
Attached patch fixes this problem and also cleans up BookKeeperAdmin a little.
There were a lot of nested callbacks nested in more callbacks etc. I've tries
to unnest a little.
Ledger metadata is now updated on each fragment. It used to be updated when the
whole ledger was recovered, but only specified a single possible ledger. This
was incorrect as it could lead to underreplication. There can be contention in
the writes to the ledger data, but just retry as the previously successful
write should have updated the stat, and they will be writing from the same
ledger handle.
I've also added a couple of tests and some test framework stuff to verify that
entries are all replicated.
> 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
> 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
