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

Chia-Ping Tsai commented on HBASE-18295:
----------------------------------------

bq. Can you confirm once?
Copy that. I will try it later. 

bq. INCLUDE_SEEK_NEXT_COL does not happen
Actually, the bug is not going to happen because the cell INCLUDED is the 
current top cell. The cell exists in both of memstore scanner and hfile scanner 
so it MUST be the new top cell after reopen. In short, the 
INCLUDE_SEEK_NEXT_COL should not cause the change of top cell.

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

Reply via email to