[
https://issues.apache.org/jira/browse/HBASE-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876897#action_12876897
]
Todd Lipcon commented on HBASE-2670:
------------------------------------
I think I'm understanding the issue here. Here's my theory:
When we reseek, we reseek to the keyvalue that was previously the "next" in the
scanner by way of peeking before reseeking. However, the peek takes into
account the old read point, so we get a situation where our peek sees the old
version of a column that has multiple versions, and we seek there. Then when we
seek forward from there, we see the rows with newer timestamps because we're no
longer restricted by the old read point.
I'm working on a test case and patch.
> Reader atomicity broken in trunk
> --------------------------------
>
> Key: HBASE-2670
> URL: https://issues.apache.org/jira/browse/HBASE-2670
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.21.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Blocker
>
> There appears to be a bug in HBASE-2248 as committed to trunk. See following
> failing test:
> http://hudson.zones.apache.org/hudson/job/HBase-TRUNK/1296/testReport/junit/org.apache.hadoop.hbase/TestAcidGuarantees/testAtomicity/
> Think this is the same bug we saw early on in 2248 in the 0.20 branch, looks
> like the fix didn't make it over.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
