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-13916) Create MultiByteBuffer
Date Thu, 18 Jun 2015 05:34:00 GMT

    [ 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

View raw message