[
https://issues.apache.org/jira/browse/HBASE-10531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933617#comment-13933617
]
Andrew Purtell commented on HBASE-10531:
----------------------------------------
bq. So we can have one off heap buffer backed ByteRange impl also (During the
offheap work)
Right. ByteRange will need to evolve, but we can take care to avoid issues with
using ByteBuffer directly that are suboptimal for us, such as the inability to
inline get* and put* methods, or bounds checking we can elide. Also we could
have multiple allocators for on and off heap arenas, at least in the beginning
while we are sorting this all out, backed by JDK ByteBuffer, Netty ByteBuf, IBM
Java BoxedPackedObject (just an example of something more esoteric), and so on.
> Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo
> ------------------------------------------------------------------------
>
> Key: HBASE-10531
> URL: https://issues.apache.org/jira/browse/HBASE-10531
> Project: HBase
> Issue Type: Sub-task
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Fix For: 0.99.0
>
> Attachments: HBASE-10531.patch, HBASE-10531_1.patch,
> HBASE-10531_2.patch
>
>
> Currently the byte[] key passed to HFileScanner.seekTo and
> HFileScanner.reseekTo, is a combination of row, cf, qual, type and ts. And
> the caller forms this by using kv.getBuffer, which is actually deprecated.
> So see how this can be achieved considering kv.getBuffer is removed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
