[
https://issues.apache.org/jira/browse/HBASE-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900553#action_12900553
]
ryan rawson commented on HBASE-2856:
------------------------------------
That sounds possible... the extra memory held could be up to 64mb *
block-size * # of families. Ie: a few hundred megs or even gigs.
https://issues.apache.org/jira/browse/HBASE-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900535#action_12900535]
Currently, after every flush we are notifying the scanners (called as
observers) so that they update their heap. If we do not notify them about
the flush, the scanner wouldn't encounter any inconsistencies. This should
solve the specific problem you discussed above where flushing results in
inconsistency. This seems like an easy change and maintains correctness. The
only drawback is that we are holding some memstore keys for a little longer
which doesn't seem too big of a problem.
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.
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).
> 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.
