[
https://issues.apache.org/jira/browse/HBASE-18295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071958#comment-16071958
]
Chia-Ping Tsai commented on HBASE-18295:
----------------------------------------
bq. And also should the cases as in the patch be handled in other places where
we call seekAsDirection() during the course of a next()?
{code}
protected final boolean reopenAfterFlush() throws IOException {
...
resetKVHeap(this.currentScanners, store.getComparator());
resetQueryMatcher(lastTop);
if (heap.peek() == null || store.getComparator().compareRows(lastTop,
this.heap.peek()) != 0) {
if (LOG.isDebugEnabled()) {
LOG.debug("Storescanner.peek() is changed where before = " +
lastTop.toString() +
",and after = " + heap.peek());
}
return true;
}
return false;
}
{code}
The matcher will be reset if the lastTop has been changed to the next row.
{code}
private void resetQueryMatcher(Cell lastTopKey) {
// Reset the state of the Query Matcher and set to top row.
// Only reset and call setRow if the row changes; avoids confusing the
// query matcher if scanning intra-row.
Cell cell = heap.peek();
if (cell == null) {
cell = lastTopKey;
}
if ((matcher.currentRow() == null) || !CellUtil.matchingRows(cell,
matcher.currentRow())) {
this.countPerRow = 0;
// The setToNewRow will call reset internally
matcher.setToNewRow(cell);
}
}
{code}
Hence, the matcher will accept the changed 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)
