-
Notifications
You must be signed in to change notification settings - Fork 3.4k
SEEK_NEXT_USING_HINT is ignored on reversed Scans [HBASE-26232] #3639
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…ns, and add tests to validate this behavior.
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fix.
Just a simple overhead needs to be fixed. And please also fix the checkstyle issues.
@@ -737,7 +737,10 @@ public boolean next(List<Cell> outResult, ScannerContext scannerContext) throws | |||
|
|||
case SEEK_NEXT_USING_HINT: | |||
Cell nextKV = matcher.getNextKeyHint(cell); | |||
if (nextKV != null && comparator.compare(nextKV, cell) > 0) { | |||
if (nextKV != null && | |||
((!scan.isReversed() && comparator.compare(nextKV, cell) > 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's only do one compare and record the result and use it in the if condition? Here we are on the critial read path, so let's try to avoid extra compare as much as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Java's && short-circuits, so the comparison is only ever actually run once. If the isReversed
check (either the normal or the negated) fails, we don't do the associated comparison.
However, I agree that it would be clearer that only one comparison is performed if we store the result. Updated.
I also removed the extraneous @throws
doc tags; they were left over when copying from TestFuzzyRowFilterEndToEnd
.
P. S. Do you know why GitHub says there were test failures, but the linked "details" page doesn't report any (besides a known failure)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, thank you for making it more clear.
On the broken PR state, it is because this issue
https://issues.apache.org/jira/browse/SUREFIRE-1821
We enable flaky rerun feature and once there are some flaky tests, the xml report will be broken and fail the report generation stage of the jenkins job, which will finally lead a broken state here.
Still trying to solve the problem but not a blocker for merging here.
...between the current row and the hint when seeking. Also, clean up extraneous doc annotations that explain nothing.
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
The failed UTs are related? |
Yes, my mistake. I accidentally moved the comparison before the null check when separating it out. Fixed. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
Signed-off-by: Duo Zhang <zhangduo@apache.org>
Signed-off-by: Duo Zhang <zhangduo@apache.org>
Signed-off-by: Duo Zhang <zhangduo@apache.org>
A fix and tests for [HBASE-26232]