[
https://issues.apache.org/jira/browse/BOOKKEEPER-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420458#comment-13420458
]
Uma Maheswara Rao G commented on BOOKKEEPER-348:
------------------------------------------------
Yep, that is the current behaviour.
We have implemented the work arond for reading that entry in LedgerChecker by
having our own logic to detemine the last entry.
Infact, we have some more corner cases where we still can not get correct
values. For that we have a EntryExistsCallback class for tracking whether the
entries really exist or not.
see some work related to that in BOOKKEEPER-247.
https://github.com/ivankelly/bookkeeper/commit/b85c94930a325b1cc275fee26d7d62e9e0cdc778
{code}
+ /* Checking the last segment of the ledger can be complicated in some
cases.
197 + * In the case that the ledger is closed, we can just check
the fragments of
198 + * the segment as normal.
199 + * In the case that the ledger is open, but enough entries
have been written,
200 + * for lastAddConfirmed to be set above the start entry of
the segment, we
201 + * can also check as normal.
202 + * However, if lastAddConfirmed cannot be trusted, such as
when it's lower than
203 + * the first entry id, or not set at all, we cannot be sure
if there has been
204 + * data written to the segment. For this reason, we have to
send a read request
205 + * to the bookies which should have the first entry. If they
respond with
206 + * NoSuchEntry we can assume it was never written. If they
respond with anything
207 + * else, we must assume the entry has been written, so we run
the check.
208 + */
165 209 if (curEntryId != null) {
210 + long lastEntry = lh.getLastAddConfirmed();
211 +
212 + if (lastEntry < curEntryId) {
213 + lastEntry = curEntryId;
214 + }
215 +
216 + final Set<LedgerFragment> finalSegmentFragments = new
HashSet<LedgerFragment>();
166 217 for (int i = 0; i < curEnsemble.size(); i++) {
167 - long lastEntry = lh.getLastAddConfirmed();
218 + finalSegmentFragments.add(new
LedgerFragment(lh.getId(), curEntryId,
219 + lastEntry, i,
curEnsemble,
220 +
lh.getDistributionSchedule()));
221 + }
{code}
Go through the test code, which covers many scenarios on reading entries from
diff client and that work is mainly for AutoRecovery and not committed yet.
> 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
