[
https://issues.apache.org/jira/browse/HBASE-16859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15709133#comment-15709133
]
Hadoop QA commented on HBASE-16859:
-----------------------------------
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 6s {color}
| {color:red} HBASE-16859 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.3.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12841078/HBASE-16859_V2.patch |
| JIRA Issue | HBASE-16859 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4720/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Use Bytebuffer pool for non java clients specifically for scans/gets
> --------------------------------------------------------------------
>
> Key: HBASE-16859
> URL: https://issues.apache.org/jira/browse/HBASE-16859
> Project: HBase
> Issue Type: Sub-task
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-16859_V1.patch, HBASE-16859_V2.patch
>
>
> In case of non java clients we still write the results and header into a on
> demand byte[]. This can be changed to use the BBPool (onheap or offheap
> buffer?).
> But the basic problem is to identify if the response is for scans/gets.
> - One easy way to do it is use the MethodDescriptor per Call and use the
> name of the MethodDescriptor to identify it is a scan/get. But this will
> pollute RpcServer by checking for scan/get type response.
> - Other way is always set the result to cellScanner but we know that
> isClientCellBlockSupported is going to false for non PB clients. So ignore
> the cellscanner and go ahead with the results in PB. But this is not clean
> - third one is that we already have a RpccallContext being passed to the RS.
> In case of scan/gets/multiGets we already set a Rpccallback for shipped call.
> So here on response we can check if the callback is not null and check for
> isclientBlockSupported. In this case we can get the BB from the pool and
> write the result and header to that BB. May be this looks clean?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
