Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 13 Oct 2016 17:34:20 +0000 (UTC)
From: "Anoop Sam John (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12965573.1462537103000.819646.1476380060839@Atlassian.JIRA>
In-Reply-To: <JIRA.12965573.1462537103000@Atlassian.JIRA>
References: <JIRA.12965573.1462537103000@Atlassian.JIRA> <JIRA.12965573.1462537103111@arcas>
Subject: [jira] [Commented] (HBASE-15789) PB related changes to work with
 offheap
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 13 Oct 2016 17:34:23 -0000


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

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

bq.Should this be protected rather than default?
As it is static I thought default is make sense than protected

bq.public int read(int offset, byte b[]) throws IOException {
Just added it to look some what like IS

bq.Do we need a readLazy to go w/ the ByteOutput writeLazy?
Not sure. WHat we actually need is a way to have an offset addressable abstraction of the input src. (Ours is not byte[] or BB). PB is having IS based CIS but IS dont have offset accessibility. And it need temp buffers and copy to there.  So readLazy am not sure what can be the usage.

bq.Is the size needed? A buffer will always have a size?
It is.  At first when we make an instance of the new CIS, offset or length is not necessary. The ByteInput impl internally can have both offset and length.  From a CIS one can make ByteStrings.  So we will be making ByteInputByteString. There any way offset and length needs to be present. There is an API in ByteString to make a CIS from it. That is CIS over the entire bytes of this ByteString. There we will need to pass offset and length.

bq.Is there a ByteOutput version of ByteInputByteString ?
That is not needed no? To COS and to ByteOutput we will write ByteStrings.  ByteInput is some thing liek a byte[] or BB and so we will need ByteInputBS.

bq.Did you try ByteInput with a ByteBuf offheap?
Yes tested.  I added support to read RPC reqs into BBs from pool. So we read reqs into N off heap BBs and make a ByteBuff wrapping them. From this only we will read PB objects like Header, params etc and CellScanner also..  So I made a ByteBuff based ByteInput impl.  

Thanks for checking Stack.

> PB related changes to work with offheap
> ---------------------------------------
>
>                 Key: HBASE-15789
>                 URL: https://issues.apache.org/jira/browse/HBASE-15789
>             Project: HBase
>          Issue Type: Sub-task
>          Components: regionserver
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: Anoop Sam John
>             Fix For: 2.0.0
>
>         Attachments: HBASE-15789.patch, HBASE-15789_V2.patch
>
>
> This is an issue to brainstorm. Whether we go with pb 2.x or pb 3.0 and also depends on the shading of protobuf classes. 
> We should also decide if we are going to fork the PB classes.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)