hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HBASE-2856) TestAcidGuarantee broken on trunk
Date Fri, 10 Dec 2010 00:09:02 GMT

     [ https://issues.apache.org/jira/browse/HBASE-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

stack updated HBASE-2856:
-------------------------

    Attachment: 2856-v2.txt

This patch adds sequence number to KeyValue.  Also adds handling of version (version of KV
is an internal detail, not let out of KV).  All current TestKeyValue tests pass but everything
else is broke currently.

The new KV particle is called sequence number.  Its looking like this sequence number could
be the HRS sequence id.  I've purposely not made connection between the two.  We'll start
out with HRS sequence id == KV sequence number but this may change at some later time.

Will next make RWCC use the KV sequence number instead of the KV data member it used keep
up.

> 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, 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.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message