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