[
https://issues.apache.org/jira/browse/BOOKKEEPER-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420135#comment-13420135
]
Flavio Junqueira commented on BOOKKEEPER-348:
---------------------------------------------
Hi Wangda, Thanks for reporting this issue. Let me raise a couple of points
about it:
# If the bug you're reporting is legitimate, then I wonder why
LedgerRecoveryTest is not failing. It should be failing and I believe it isn't.
# The method you're modifying in your patch is to really fetch the last add
confirmed, so your patch actually breaks its semantics. It is called in
ReadLastConfirmedOp.
What do you think?
> Last entry will be lost when open an un-closed ledger
> ------------------------------------------------------
>
> Key: BOOKKEEPER-348
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-348
> Project: Bookkeeper
> Issue Type: Bug
> Components: bookkeeper-client
> Affects Versions: 4.1.0
> Reporter: Wangda Tan
> Attachments: BookKeeper-348.patch
>
>
> This can be reproduced in following steps:
> 1) client-A created a ledger-x and write N entries to it
> 2) client-B open the ledger-x and try to read all entries from it. client-B
> can only get N-1 entries (except for the last entry)
> This problem caused by, when trying to open an unclosed ledger, it will enter
> the "recover" mode, it can get correct last entry-Id judged by the size of
> log file. But it will set the new opened ledger's lastAddConfirmed by the
> previous lastAddConfirmed, and the entry-id will be ignored.
> For an unclosed ledger, the lastAddConfirmed will always = (last-entry-id -
> 1).
> A patch attached to this jira.
--
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
