[
https://issues.apache.org/jira/browse/HBASE-18295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071944#comment-16071944
]
ramkrishna.s.vasudevan commented on HBASE-18295:
------------------------------------------------
Nice work [~chia7712]. Few questions on the patch
While doing next() - if the return code is to do seekOrSkipToNextColumn(cell),
we check if the flush has happened and if so reopenAfterFlush() is done.
Currently the return value is not used when a reseek() call happens.
Now if this reseek() happens during a next() call even if the lastTop has
changed the cell to the nextRow, the subsquent call to matcher.match() on the
heap.peek() (which should ideally be the lastTop) should say
{code}
// if row key is changed, then we know that we have moved over to the next
row
if (rowComparator.compareRows(currentRow, cell) != 0) {
return MatchCode.DONE;
}
{code}
And also should the cases as in the patch be handled in other places where we
call seekAsDirection() during the course of a next()?
> 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)
