Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 3 Feb 2011 19:51:29 +0000 (UTC)
From: "ryan rawson (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <301536894.8237.1296762689676.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Commented: (HBASE-2856) TestAcidGuarantee broken on trunk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990261#comment-12990261 ] 

ryan rawson commented on HBASE-2856:
------------------------------------

i dont think bulk load is an issue, since we only call update readers between rows (once we move the update readers to the HRegion.Scanner level), then it will be an atomic 'appearance' of data. Does that sound right?

> 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: stack
>            Priority: Blocker
>             Fix For: 0.92.0
>
>         Attachments: 2856-v2.txt, 2856-v3.txt, 2856-v4.txt, 2856-v5.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.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira