hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2856) TestAcidGuarantee broken on trunk
Date Fri, 20 Aug 2010 23:50:19 GMT

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

stack commented on HBASE-2856:
------------------------------

@Ryan Thanks for writing this up.   Useful.  My thinking is that the extra ts/version is too
much to do just now as we're coming up fast on a 0.90.x.  Its a 0.92.x project I'm thinking
especially as I think it'll take a bit of work to implement it so migration is done at runtime.
 Also, following on from the Pranav suggestion, for now, can we not just let the scanner exhaust
the current row only against whatever was in memstore rather than let the scanner run to the
end of the region and then when it reaches the end of the row, then let go of memstore reference?
 In other words, only at row junctures update its memstore/hfile scanner set?

> 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: ryan rawson
>            Priority: Blocker
>             Fix For: 0.90.0
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message