[ 
https://issues.apache.org/jira/browse/HBASE-16859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584545#comment-15584545
 ] 

Anoop Sam John commented on HBASE-16859:
----------------------------------------

We dont need to add any extension to CIS or COS.  COS already having ByteOuput 
based extension and this is from 3.1 release itself.  ByteInput support for CIS 
is added (yet to be committed and there were some issue with the patch apply 
step in scripts. Stack will is on to it). 
Now we will need to implement ByteOutput for COS which works with ByteBuff.  
That impl class to be within hbase-server package only. (Where u have RpcServer)

> 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
>
>
> 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)

Reply via email to