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)