[
https://issues.apache.org/jira/browse/HBASE-18295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074262#comment-16074262
]
Guanghao Zhang commented on HBASE-18295:
----------------------------------------
bq. The flusher doesn't skip the cells VISIBLE for current user scans. Hence,
all cells INCLUDED for current scan should exist in somewhere after we replace
the memstore scanner by corresponding hfile scanner.
Thanks for your explanation. This was guaranteed by smallest readPoint, right?
> The result contains the cells across different rows
> ----------------------------------------------------
>
> Key: HBASE-18295
> URL: https://issues.apache.org/jira/browse/HBASE-18295
> Project: HBase
> Issue Type: Bug
> Reporter: Chia-Ping Tsai
> Assignee: Chia-Ping Tsai
> Priority: Blocker
> Fix For: 3.0.0, 1.4.0, 1.3.2, 2.0.0-alpha-2
>
> Attachments: HBASE-18295.branch-1.3.v0.patch,
> HBASE-18295.branch-1.v0.patch, HBASE-18295.v0.patch, HBASE-18295.v1.patch
>
>
> From the [flaky
> dashboard|https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html]
> If we use the cell which won't be flushed into disk as the top cell to reopen
> the scanners, the new top cell will change. If the new top cell is in
> different row, the matcher will reset, and then matcher will accept the new
> top cell...
> The TestStore# testFlushBeforeCompletingScan reproduces the bug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
