[
https://issues.apache.org/jira/browse/HBASE-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056971#comment-14056971
]
Ted Yu commented on HBASE-11487:
--------------------------------
Not sure what happened in the code below (dev-support/smart-apply-patch.sh):
{code}
if ! grep -qv '^a/\|^b/' $TMP2 ; then
echo Looks like this is a git patch. Stripping a/ and b/ prefixes
echo and incrementing PLEVEL
{code}
If you can attach patch of level 1, QA should accept it.
Thanks for the patch - looks good.
> 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)
