[
https://issues.apache.org/jira/browse/HBASE-13916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14588446#comment-14588446
]
Anoop Sam John commented on HBASE-13916:
----------------------------------------
bq,Is the fact that the nature of MBB changes based on whether there is one BB
or many BBs going to confuse? Why not just throw unsupported whatever the BB
count in methods like array, arrayOffset, etc.
HFileBlock is going to be backed by MBB. I wanted like when the block comes
NOT from L2 cache, we will go like in existing way and make KeyValue. when we
make Cell objects in read path, based on this hasArray() we will have to make
either byte[] backed KVs or BB backed new objects. Just because of this I
thought of keeping this hasArray() true when MBB is backed by a single on heap
BB.
bq.I think the class comment should describe when to use this rather than
ByteBufferArray from util.
I will clean it.
bq.Why a getVLong in here? That belongs outside this class?
Just did not want a new util class for it. Let me see.
bq.Is the unsafe work going on in BBUtils dupe of Bytes unsafeing? Should the
BBUtils go to Bytes for Unsafe ops?
Not really. When it is BB we will have to deal with isDirect case also. There
is an UnsafeAccess class now.. May be all these byte[] and BB related unsafe
access has to go in there and Bytes and BBUtils etc has to use that. (?)
> 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
>
>
> 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)
