hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-11487) ScanResponse carries non-zero cellblock for CloseScanRequest (ScanRequest with close_scanner = true)
Date Fri, 11 Jul 2014 17:40:05 GMT

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

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

    Attachment: HBASE-11487-0.98.patch

> 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-0.98.patch, 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)

Mime
View raw message