hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shengzhe Yao (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HBASE-11487) ScanResponse carries non-zero cellblock for CloseScanRequest (ScanRequest with close_scanner = true)
Date Wed, 09 Jul 2014 23:58:04 GMT
Shengzhe Yao created HBASE-11487:
------------------------------------

             Summary: 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


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