[
https://issues.apache.org/jira/browse/HBASE-18295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16075851#comment-16075851
]
Chia-Ping Tsai commented on HBASE-18295:
----------------------------------------
bq. So even after filter, we return SEEK_NEXT_ROW or SEEK_NEXT_USING_HINT,
there is no chance to change the top cell
I paste some codes from the v18.patch of HBASE-17125.
{code}
+ matchCode = columns.checkVersions(cell, timestamp, typeByte, false);
+ switch (matchCode) {
+ case SKIP:
+ return MatchCode.SKIP;
+ case SEEK_NEXT_COL:
+ return MatchCode.SEEK_NEXT_COL;
+ default:
+ // It means it is INCLUDE, INCLUDE_AND_SEEK_NEXT_COL or
INCLUDE_AND_SEEK_NEXT_ROW.
+ assert matchCode == MatchCode.INCLUDE || matchCode ==
MatchCode.INCLUDE_AND_SEEK_NEXT_COL
+ || matchCode == MatchCode.INCLUDE_AND_SEEK_NEXT_ROW;
+ break;
+ }
+
+ return filter == null ? matchCode : mergeFilterResponse(cell, matchCode,
+ filter.filterKeyValue(cell));
{code}
If columns#checkVersions() says SEEK_NEXT_COLUMN, we will return it directly
w/o filter response. The UTs in this jira have columns#checkVersions() say
SEEK_NEXT_COLUMN for triggering the bugs so i said "the filter.filterKeyValue
isn't evaluated".
bq. how about setScannerState in the needToReturn method internal and let
needToReturn method return a bool value? Then we can skip the null check.
Good idea. Thanks.
By the way, I apply v18.patch of HBASE-17125 and v2.patch of this jira. Then,
the testFlushBeforeCompletingScanWithFilter fails.
> 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,
> HBASE-18295.v2.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)
