[jira] [Commented] (HBASE-11487) ScanResponse carries non-zero cellblock for CloseScanRequest (ScanRequest with close_scanner = true)

["Hadoop QA (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056922#comment-14056922 ] 

Hadoop QA commented on HBASE-11487:
-----------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12654896/HBase_11487_v1.patch
  against trunk revision .
  ATTACHMENT ID: 12654896

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:red}-1 tests included{color}.  The patch doesn't appear to include any new or modified tests.
                        Please justify why no new tests are needed for this patch.
                        Also please list what manual steps were performed to verify this patch.

    {color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/10006//console

This message is automatically generated.

> ScanResponse carries non-zero cellblock for CloseScanRequest (ScanRequest with close_scanner = true)
> ----------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-11487
>                 URL: https://issues.apache.org/jira/browse/HBASE-11487
>             Project: HBase
>          Issue Type: Bug
>          Components: IPC/RPC, regionserver
>    Affects Versions: 0.96.2, 0.99.0, 2.0.0
>            Reporter: Shengzhe Yao
>            Assignee: Shengzhe Yao
>            Priority: Minor
>             Fix For: 2.0.0
>
>         Attachments: HBase_11487_v1.patch
>
>
> After upgrading hbase from 0.94 to 0.96, we've found that our asynchbase client keep throwing errors during normal scan. It turns out these errors are due to Scanner.close call in asynchbase. Since asynchbase assumes the ScanResponse of CloseScannerRequest should never carry any cellblocks, it will throw an exception if there is a violation.
> In the asynchbase client (1.5.0), it constructs a CloseScannerRequest in the following way,  
>    ScanRequest.newBuilder()
>         .setScannerId(scanner_id)
>         .setCloseScanner(true)
>         .build();
> Note, it does not set numOfRows, which kind of make sense. Why a close scanner request cares about number of rows to scan ?
> However, after narrowing down the CloseScannerRequest code path, it seems the issue is on regionserver side. In RsRpcServices.scan, we always init numOfRows to scan to 1 and we do this even for ScanRequest with close_scanner = true. This causes response for CloseScannerRequest will carry a cellBlock (if scan stops before the end row and this could happen in many normal scenarios)
> There are two fixes, either we always set numOfRows in asynchbase client side when constructing a CloseScannerRequest or we fix the default value in the server side.
> From a hbase client side point of view, it seems make less sense that server will send you a cellBlock for your close scanner request, unless the request explicitly asks for. 
> We've made the change in our server code and the asynchbase client errors goes away. 
> In addition to this issue, I want to know if we have any specifications for our hbase rpc. Like if close_scanner = true in ScanRequest and numOfRows is not set, ScanResponse guarantees that there is no cellBlock in the response. Since we moved to protobuf and many fields are optional for compatibility consideration, it might be helpful to have such specification which helps people to develop code that depends on hbase rpc.     



--
This message was sent by Atlassian JIRA
(v6.2#6252)