You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Lars Hofhansl (Issue Comment Edited) (JIRA)" <ji...@apache.org> on 2011/11/20 20:21:51 UTC
[jira] [Issue Comment Edited] (HBASE-2856) TestAcidGuarantee broken
on trunk
[ https://issues.apache.org/jira/browse/HBASE-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153852#comment-13153852 ]
Lars Hofhansl edited comment on HBASE-2856 at 11/20/11 7:20 PM:
----------------------------------------------------------------
@Nicolas and @Amit, could you review the 0.92 patch? I turned out to be much more manual than I had wished or expected, so it is very possible that I missed something.
(I tried to upload the 0.92 patch to review board for easier verification, but apparently that does not work for branches other than trunk.)
was (Author: lhofhansl):
@Nicolas and @Amit, could you review the 0.92 patch? I turned out to be much more manual than I had wished or expected, so it is very possible, that I missed something.
(I tried to upload the 0.92 patch to review board for easier verification but apparently that does not work for branches other than trunk.)
> TestAcidGuarantee broken on trunk
> ----------------------------------
>
> Key: HBASE-2856
> URL: https://issues.apache.org/jira/browse/HBASE-2856
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.89.20100621
> Reporter: ryan rawson
> Assignee: Amitanand Aiyer
> Priority: Blocker
> Fix For: 0.94.0
>
> Attachments: 2856-0.92.txt, 2856-v2.txt, 2856-v3.txt, 2856-v4.txt, 2856-v5.txt, 2856-v6.txt, 2856-v7.txt, 2856-v8.txt, 2856-v9-all-inclusive.txt, acid.txt
>
>
> TestAcidGuarantee has a test whereby it attempts to read a number of columns from a row, and every so often the first column of N is different, when it should be the same. This is a bug deep inside the scanner whereby the first peek() of a row is done at time T then the rest of the read is done at T+1 after a flush, thus the memstoreTS data is lost, and previously 'uncommitted' data becomes committed and flushed to disk.
> One possible solution is to introduce the memstoreTS (or similarly equivalent value) to the HFile thus allowing us to preserve read consistency past flushes. Another solution involves fixing the scanners so that peek() is not destructive (and thus might return different things at different times alas).
--
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