[
https://issues.apache.org/jira/browse/HBASE-13916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14591281#comment-14591281
]
Anoop Sam John commented on HBASE-13916:
----------------------------------------
bq.MBB is NOT a BB (because you can't subclass BB). If so, pardon me. Move
getVlong back to MBB and commit.
Yes BB can not be subclass is an issue for us.. Else it was not required to
change the HFileBlock's backing data type. Ok I will move it back to MBB only
then. That seems better.
bq.But when we call getVlong, are we not positioned at a place form where we
can read a vlong?
You mean our current position on an item BB from where we can read? Yes we are.
But outside users dont have access to individual item BBs. A vlong might be
tsored with say 5 bytes. We are positioned at 2nd last byte of the current item
BB. So this vlongs 2 bytes comes from current BB and next 3 from next BB.
> Create MultiByteBuffer
> ----------------------
>
> Key: HBASE-13916
> URL: https://issues.apache.org/jira/browse/HBASE-13916
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-13916.patch, HBASE-13916_V2.patch,
> HBASE-13916_V3.patch
>
>
> This is an aggregation of N ByteBuffers. The block when served directly by
> block cache buckets memory, we have the block data split across multiple byte
> buffers. This aggregate type (like ByteBuffer) will serve the HFileBlock data.
> This jira wil just provide the new data structure
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
