[ https://issues.apache.org/jira/browse/HBASE-18295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073145#comment-16073145 ]
Anoop Sam John commented on HBASE-18295: ---------------------------------------- Thanks for digging in these kind of very difficult to solve bugs. {code} // If the top cell won't be flushed into disk, 700 // the new top cell may be changed after #reopenAfterFlush. 701 // Because the older top cell only exist in the memstore scanner but the memstore 702 // scanner is replaced by hfile scanner after #reopenAfterFlush. 703 // If the row of top cell is changed, we should return the current cells. 704 // Otherwise, we may return the cells across different rows. 705 if (!outResult.isEmpty() && topChanged) { 706 return scannerContext.setScannerState(heap.peek() == null ? 707 NextState.NO_MORE_VALUES : NextState.MORE_VALUES).hasMoreValues(); 708 } {code} This means we will split that current row into more than one result. In normal case that would have been going as single result correct. Any way that is expected at any time as we may do it if that scanner reaches some max result size or so. But we will mark it correctly? Sorry I did not see in detail the code part. Just asking after reading ur comments > 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)