hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16859) Use Bytebuffer pool for non java clients specifically for scans/gets
Date Thu, 01 Dec 2016 06:50:58 GMT

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

Mime
View raw message