hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Sigoure (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17489) ClientScanner may send a next request to a RegionScanner which has been exhausted
Date Mon, 08 May 2017 20:39:04 GMT

    [ 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:
    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());

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

View raw message