[
https://issues.apache.org/jira/browse/BOOKKEEPER-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420459#comment-13420459
]
Rakesh R commented on BOOKKEEPER-348:
-------------------------------------
@Wangda,
Please see the similar behaviour is shown in one of the existing test case in
BK. This may help you better understanding.
{code}
org.apache.bookkeeper.client.TestFencing.testFencingInteractionWithBookieRecovery2()
//....
//....
try {
writelh.close();
fail("Should fail trying to update metadata");
} catch (BKException.BKMetadataVersionException e) {
// correct behaviour
}
{code}
> 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
