[
https://issues.apache.org/jira/browse/HBASE-10573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917695#comment-13917695
]
Matt Corgan commented on HBASE-10573:
-------------------------------------
[~apurtell] on HBASE-10191{quote}We could make the investment of writing our
own slab allocator. Experiments with Netty 4 ByteBufs are in part about seeing
if we can re-use open source in production already rather than redo the work.
On the other hand, it could be a crucial component so maybe it's necessary to
have complete control. Perhaps we can move additional comments on this
sub-topic over to HBASE-10573?{quote}Writing from scratch does seem attractive
for keeping it simple and targeted at hbase's use cases. It could probably be
hbase-unaware and have a dedicated test suite. The basic concepts are pretty
straightforward - most of the complexity would probably arise in concurrency
related operations like ref-counting to know when a slab is 100% safe to
recycle. When a block is copied to a new slab, new readers can use the new
location, and old readers can still use the block on the old slab, but you have
to be sure to wait for all the old readers to finish before recycling the slab.
You have to wait for straggling readers and be sure to decrement the
ref-counts for errored readers, etc.
> Use Netty 4
> -----------
>
> Key: HBASE-10573
> URL: https://issues.apache.org/jira/browse/HBASE-10573
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: hbase-10191
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Attachments: 10573.patch
>
>
> Pull in Netty 4 and sort out the consequences.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
