hbase-issues mailing list archives

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

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

ramkrishna.s.vasudevan edited comment on HBASE-16859 at 12/1/16 6:56 AM:
-------------------------------------------------------------------------

bq.hat should be a miss! Raise a new issue to push this change into shaded PB of ours
Will do that. Probably there is one more thing.
In CIS the ByteIutputDecoder was directly working on the ByteInput.
Now in COS we have an AbstractBufferedEncoder extended by ByteOutputEncoder.
So apart from the ByteOutput we also have the byte[] inside AbstractBufferedEncoder .
So when we try to write the UINT part we write to this byte[] and that is in turn getting
flushed later to the ByteOutput as a byte[] or buffer.
In ARrayEncoder and BBEncoder we don't do this way. We directly write to the byte[] and BB.
It is not an issue but the byte[] we init is additional and we have two level copies.



was (Author: ram_krish):
bq.hat should be a miss! Raise a new issue to push this change into shaded PB of ours
Will do that. Probably there is one more thing.
In CIS the ByteIutputDecoder was directly working on the ByteInput.
Now in COS we have an AbstractBufferedEncoder extended by ByteOutputEncoder.
So apart from the ByteOutput we also have the byte[] inside AbstractBufferedEncoder .
So when we try to write the unit part we write to this byte[] and that is in turn getting
flushed later to the ByteOutput as a byte[] or buffer.
In ARrayEncoder and BBEncoder we don't do this way. We directly write to the byte[] and BB.
It is not an issue but the byte[] we init is additional and we have two level copies.


> 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