[
https://issues.apache.org/jira/browse/HBASE-10573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13907272#comment-13907272
]
Andrew Purtell commented on HBASE-10573:
----------------------------------------
bq. perhaps except for ByteBuffers + some reflection voodoo
Voodoo is kind of nonspecific as far as implementation strategy descriptions
go. :-)
I guess we need to reuse such a wrapper object if we must take a
reflection-based instantiation hit each time.
bq. DirectByteBuffers + reflection does open up the possibility of using the
unsafe directly to manage memory, which may be desirable.
Isn't this undesirable? Unsafe is a vendor specific extension. Even then Oracle
recently ran a public survey asking what uses of Unsafe are common and what
would happen if it went away. We do use Unsafe and have some exposure to this,
but do have an un-Unsafe fallback in those places.
bq. This has the benefit of sticking with the JVM "native" APIs,
Don't the "native" ByteBuffer method calls tend not to be inlined? I have heard
the complaint but have not personally examined JIT disassembly (yet). Aren't
there boundary checks and index compensations sprinkled throughout? (which
Netty does away with in the simple ByteBuf types)
bq. As you say, more investigation is necessary
Great, let's proceed. At the moment this issue is about what happens if you
even try to bring in 4. On that, N pointed me to TestHCM#testClusterStatus,
which tests the multicast status publisher he implemented with Netty 3
channels. My port of that to Netty 4 APIs fails if I remove the @Ignore
decoration, so I don't have it right yet.
> 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.1.5#6160)
