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

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

You guys have iet right, that you can't know the next row until you
are already past the first key.

The problem is that we would have to hold on to the snapshot and kvset
until the end of the scanner when it is closed.  This will up our
chance of preventable OOME, but it would depend on the scanner use
patterns. It seems risky to me to take this approach.

I'm not sure we want to change the entire nature of how scanner
updates work, it would require redoing the heap a bit to bubble update
scanner events down.  I'm not sure how complex that patch would be,
there is no way to easily know until the work is done.  But without
either of those two approaches, this JIRA may have to be a 0.92 issue.






> 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.

Reply via email to