[
https://issues.apache.org/jira/browse/HBASE-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16001480#comment-16001480
]
Benoit Sigoure commented on HBASE-17489:
----------------------------------------
AsyncHBase expects the scanner ID in response to scanning more rows but that's
not actually necessary. I think I added this as a sanity check because I
expected the server to always return the ID, but as was said above it's
technically not strictly necessary for the server to return the ID on
subsequent uses of the scanner.
The code doesn't even do anything with the scanner ID other than checking that
it's the ID we expected:
{code}
@Override
Response deserialize(final ChannelBuffer buf, final int cell_size) {
final ScanResponse resp = readProtobuf(buf, ScanResponse.PARSER);
final long id = resp.getScannerId();
if (scanner_id != id) {
throw new InvalidResponseException("Scan RPC response was for scanner"
+ " ID " + id + " but we expected"
+ scanner_id, resp);
}
final ArrayList<ArrayList<KeyValue>> rows = getRows(resp, buf, cell_size);
if (rows == null) {
return null;
}
return new Response(resp.getScannerId(), rows, resp.getMoreResults());
}
{code}
I guess we could fix this by saying "if we have a scanner ID in the response
THEN it must match the one expect" instead of "there must be a scanner ID in
the response that matches what we expect".
Ironically we had the same bug in GoHBase, where we made the same assumption
that the scanner ID was always present in the response.
> ClientScanner may send a next request to a RegionScanner which has been
> exhausted
> ---------------------------------------------------------------------------------
>
> Key: HBASE-17489
> URL: https://issues.apache.org/jira/browse/HBASE-17489
> Project: HBase
> Issue Type: Bug
> Components: Client, scan
> Affects Versions: 2.0.0, 1.3.0, 1.4.0
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Priority: Critical
> Fix For: 2.0.0, 1.4.0, 1.3.1
>
> Attachments: HBASE-17489-branch-1.3.patch,
> HBASE-17489-branch-1.patch, HBASE-17489.patch, HBASE-17489-v1.patch,
> HBASE-17489-v2.patch, HBASE-17489-v3.patch, HBASE-17489-v4.patch,
> HBASE-17489-v4.patch, HBASE-17489-v5.patch, HBASE-17489-v6.patch
>
>
> Found it when implementing HBASE-17045. Seems the final result of the scan is
> correct but no doubt the logic is broken. We need to fix it to stop things
> get worse in the future.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
