[
https://issues.apache.org/jira/browse/HBASE-16859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858984#comment-15858984
]
ramkrishna.s.vasudevan commented on HBASE-16859:
------------------------------------------------
I will rebase this patch and go for commit later today.
> 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,
> HBASE-16859_V2.patch, HBASE-16859_V4.patch, HBASE-16859_V5.patch,
> HBASE-16859_V6.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.15#6346)
