[
https://issues.apache.org/jira/browse/HBASE-16859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15711097#comment-15711097
]
Anoop Sam John commented on HBASE-16859:
----------------------------------------
I saw it now. So the ByteOuput is treated the same was as an OS. Am not sure
then why we need a new interface. Not sure abt the intent of adding this by PB
team.. In that case, one can go with an impl of OS itself no need for a new
Byteouput. The ByteInput is created with below criteria
{code}
/**
* An input for raw bytes. This is similar to an InputStream but it is offset
addressable. All the
* read APIs are relative.
*/
@ExperimentalApi
public abstract class ByteInput {
{code}
See we say it has to be byte addressable/accessible. Means it is some what
like BB or byte[].. Its use is specifically when the input is a collection of
these kind of data structures. Then also once can make an IS around that and
use but the extra byte[] and in btw copy to there will happen. When things are
offset accessible, it is not needed. Seems like ByteOuput is designed to allow
lazy writes only
{code}
<p><b>Lazy write operations:</b> where the caller guarantees that it will
never modify the
* provided buffer and it can therefore be considered immutable. The target
method is free to
* maintain a reference to the buffer beyond the scope of the method call (e.g.
until the write
* operation completes).
{code}
> 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
>
>
> 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)
