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

Reply via email to