[
https://issues.apache.org/jira/browse/HBASE-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13951743#comment-13951743
]
stack commented on HBASE-10771:
-------------------------------
[~ndimiduk] What upstream project you thinking? And what we need to adopt
netty types? Prove that an async server better than one that starts out w/
hundreds of handlers? Or you mean netty ByteBuf? When you say "...Can we not
resolve these difficulties using subclasses, helper/utility methods, and/or
reflection?", do you mean subclasses of netty types or ByteBuffer or do you
mean subclass of ByteRange?
On why BR:
bq. ...reusable instances within a tight loop of compactions, simple(r)
interface – something I myself violated in introducing PositionedByteRange, and
more relevant comparable implementation
On being reusable, nioByteBuffer and nettyByteBuf both fail this requirement.
What is simple(r) interface? Looks like we are fast undoing this one w/ all
the additions being made herein.
.... and "...more relevant comparable implementation" prevails.
Which we seem to argue proceed with BR... but we need to fix the javadoc up in
BR so it aligns w/ these additions.
Thanks
> Primitive type put/get APIs in ByteRange
> -----------------------------------------
>
> Key: HBASE-10771
> URL: https://issues.apache.org/jira/browse/HBASE-10771
> Project: HBase
> Issue Type: Improvement
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 0.99.0
>
> Attachments: HBASE-10771.patch, HBASE-10771_V2.patch
>
>
> While doing HBASE-10713 I came across the need to write int/long (and read
> also) from a ByteRange. CellBlocks are backed by ByteRange. So we can add
> such APIs.
> Also as per HBASE-10750 we return a ByteRange from MSLAB and also discussion
> under HBASE-10191 suggest we can have BR backed HFileBlocks etc.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
