[
https://issues.apache.org/jira/browse/BOOKKEEPER-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406914#comment-13406914
]
Rakesh R commented on BOOKKEEPER-247:
-------------------------------------
@Uma @Ivan
bq.Here is one boundary case came across. When client written single entry and
waiting, at this time if one BK goes down, then Ledger checker is not able to
find that as underReplicated fragment.
I've seen the LedgerRecoveryOp.java is doing the following logic to identify
the lastAddConfirmed entry. Can we have similar stuff here also in the
replication logic if the ledger is in open state.
{code}
/**
* Try to read past the last confirmed.
*/
private void doRecoveryRead() {
lh.lastAddConfirmed++;
lh.asyncReadEntries(lh.lastAddConfirmed, lh.lastAddConfirmed, this,
null);
}
{code}
> Detection of under replication
> ------------------------------
>
> Key: BOOKKEEPER-247
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-247
> Project: Bookkeeper
> Issue Type: Sub-task
> Components: bookkeeper-client, bookkeeper-server
> Reporter: Ivan Kelly
> Assignee: Ivan Kelly
> Attachments: BOOKKEEPER-247.diff, BOOKKEEPER-247.diff,
> BOOKKEEPER-247.patch, BOOKKEEPER-247.patch
>
>
> This JIRA discusses how the bookkeeper system will detect underreplication of
> ledger entries.
--
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
