hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7320) Remove KeyValue.getBuffer()
Date Fri, 14 Feb 2014 06:06:23 GMT

    [ 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)

Mime
View raw message