You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by "Wangda Tan (JIRA)" <ji...@apache.org> on 2012/07/22 03:59:35 UTC
[jira] [Created] (BOOKKEEPER-348) Last entry will be lost when open
an un-closed ledger
Wangda Tan created BOOKKEEPER-348:
-------------------------------------
Summary: 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
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
[jira] [Commented] (BOOKKEEPER-348) Last entry will be lost when
open an un-closed ledger
Posted by "Uma Maheswara Rao G (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (BOOKKEEPER-348) Last entry will be lost when
open an un-closed ledger
Posted by "Wangda Tan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BOOKKEEPER-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420183#comment-13420183 ]
Wangda Tan commented on BOOKKEEPER-348:
---------------------------------------
Hi Flavio,
Thanks for the quick response, I found it's my fault. I mistakenly used the openNoRecovery method, so it cannot get the entries not confirmed by client.
But I found another problem when try to close the ledger, it will throw an BKException, following is the code can reproduce this problem.
{code:java}
@Test
public void testRecoverEntryInAnotherClient() throws Exception {
BookKeeper bk1 = new BookKeeper("localhost:2181");
final byte[] PASSWORD = "Password".getBytes();
final int ENTRY_COUNT = 1024;
// open the first ledger handle and add a number of entries to it
LedgerHandle lh1 = bk1.createLedger(DigestType.MAC, PASSWORD);
for (int i = 0; i < ENTRY_COUNT; i++) {
lh1.addEntry(String.valueOf(i).getBytes());
}
// open another ledger handler and try to read all entries from it
BookKeeper bk2 = new BookKeeper("localhost:2181");
LedgerHandle lh2 = bk2.openLedger(lh1.getId(), DigestType.MAC, PASSWORD);
long lastAddPushed = lh2.getLastAddPushed();
Enumeration<LedgerEntry> entries = lh2.readEntries(0, lastAddPushed);
int readCount = 0;
while (entries.hasMoreElements()) {
LedgerEntry entry = entries.nextElement();
Assert.assertEquals(Integer.valueOf(new String(entry.getEntry())).intValue(),
readCount);
readCount++;
}
Assert.assertEquals(readCount, ENTRY_COUNT);
lh1.close();
lh2.close();
bk1.close();
bk2.close();
}
{code}
The step of the program is,
1) open a ledger from BK-client-1 (named ledger-1)
2) write some entries by ledger-1
3) open a ledger from BK-client-2 (named ledger-2)
4) read entries
5) close ledger-1
the exception will throw when close ledger-1
I don't know it's the expected result or something going wrong, do you have any idea about this?
Thanks,
Wangda
> 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
[jira] [Updated] (BOOKKEEPER-348) Last entry will be lost when open
an un-closed ledger
Posted by "Wangda Tan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BOOKKEEPER-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Wangda Tan updated BOOKKEEPER-348:
----------------------------------
Attachment: BookKeeper-348.patch
attached patch for this problem, can BookKeeper team review it? Thanks a lot!
> 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
[jira] [Commented] (BOOKKEEPER-348) Last entry will be lost when
open an un-closed ledger
Posted by "Sijie Guo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BOOKKEEPER-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420396#comment-13420396 ]
Sijie Guo commented on BOOKKEEPER-348:
--------------------------------------
@Wangda, it is an expected result since the ledger has been closed by opening it from BK-client-2. so the ledger's metadata has been changed, then when BK-client-1 tried to close it, it found that metadata has been changed by other clients and could not resolve the conflict. so a MetadataVersionException would be thrown during BK-client-1 closed it.
> 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
[jira] [Commented] (BOOKKEEPER-348) Last entry will be lost when
open an un-closed ledger
Posted by "Flavio Junqueira (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (BOOKKEEPER-348) Last entry will be lost when
open an un-closed ledger
Posted by "Rakesh R (JIRA)" <ji...@apache.org>.
[ 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