[
https://issues.apache.org/jira/browse/HBASE-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948092#comment-14948092
]
ramkrishna.s.vasudevan commented on HBASE-14398:
------------------------------------------------
bq.Would getRow, getFamily without the BB be too radical? The fact that we are
doing these invocations on a class called BBC provides enough 'context' – its a
getRow against a BBC?
I would still feel having BB in the API is more convincing.
bq.If they use it against an array returned from getXXXArray, then let it mess
up... break.... IllegalArrayAccessException or whatever. getXXXOffset if BBC
should be for the BB... Let it break in CP and Filters, etc.. What you think?
So once we start doing it we will break in the write path of compaction itself
because the compaction and flushes both follow same write path. So currenlty it
is using getXXXArray() with getXXXOffset() and for a BB cell we are copying in
case of compactions. So CPs and filters have to be broken then. After a big
discussion internally here when we defined APIs we thought copying is better
than breaking and clear javadoc on BBCell should suffice. Because our earlier
patches were trying to throw Exceptions and it made the patch much bigger. So
still feel copying is better.
> Create the fake keys required in the scan path to avoid copy to byte[]
> ----------------------------------------------------------------------
>
> Key: HBASE-14398
> URL: https://issues.apache.org/jira/browse/HBASE-14398
> Project: HBase
> Issue Type: Sub-task
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-14398.patch, HBASE-14398_1.patch
>
>
> Already we have created some fake keys for the ByteBufferedCells so that we
> can avoid the copy requried to create fake keys. This JIRA aims to fill up
> all such places so that the Offheap BBs are not copied to onheap byte[].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
