Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 10 Jul 2014 20:25:05 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12726476.1404950210502.18289.1405023905723@arcas>
In-Reply-To: <JIRA.12726476.1404950210502@arcas>
References: <JIRA.12726476.1404950210502@arcas>
Subject: [jira] [Updated] (HBASE-11487) ScanResponse carries non-zero
 cellblock for CloseScanRequest (ScanRequest with close_scanner = true)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HBASE-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Purtell updated HBASE-11487:
-----------------------------------

    Fix Version/s: 0.98.4
                   0.99.0

> 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: 0.99.0, 0.98.4, 2.0.0
>
>         Attachments: HBase_11487_v1.patch, HBase_11487_v2.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)