[
https://issues.apache.org/jira/browse/HBASE-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901141#comment-13901141
]
stack commented on HBASE-7320:
------------------------------
bq. So can we make Cell of type HeapSize and Cloneable?
Cloneable makes sense.
HeapSize is how we do our accounting now so makes sense to me that we'd
implement it. But what to do when a Cell implementation is but a facade on
data that is elsewhere, not 'owned' by the Cell? For instance, say the Cell is
a facade on direct byte buffers. What will you return when I call heapSize?
(I suppose it would be the overhead the Cell consumes on heap, not the sizes of
data which is offheap?). What about when the Cell is a facade over an onheap
block? Here again you could return the Cell overhead and hope the block is
being accounted some other way. What if the Cell row, family, qualifier, type,
and ts -- i.e. the 'key' -- are onheap and the data offheap? And so on.
HeapSize is probably unavoidable. A bunch of basic mechanisms in hbase count
on it returning a decent answer.
IIRC, I suggested Cell implementing HeapSize in the past and [~mcorgan] asked
why not have size accounting done by a CellUtil method... This would probably
be awkward to call in lots of contexts but would that work?
> Remove KeyValue.getBuffer()
> ---------------------------
>
> Key: HBASE-7320
> URL: https://issues.apache.org/jira/browse/HBASE-7320
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: stack
> Fix For: 0.99.0
>
> Attachments: 7320-simple.txt
>
>
> In many places this is simple task of just replacing the method name.
> There, however, quite a few places where we assume that:
> # the entire KV is backed by a single byte array
> # the KVs key portion is backed by a single byte array
> Some of those can easily be fixed, others will need their own jiras.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
