[
https://issues.apache.org/jira/browse/FLINK-18695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17185011#comment-17185011
]
Chesnay Schepler commented on FLINK-18695:
------------------------------------------
It would be good to do another test with option 1) and 3). I'd throw out 2)
because we don't want to start balancing the netty memory usage between
heap/direct arenas.
Option 1) should behave exactly like the current code; so if this works without
side-effects it would consider it the safest option.
Option 3) should just be a better version of 1) _right now_. It shouldn't
really increase GC pressure; we create a new ByteBuf in any case (as does the
current code), and we know the JDK SSL engine already does a memory copy anyway
if it is given direct memory. But [~zjwang] made a good point in that we don't
know what else might be allocating heap buffers in the future, and this seems
difficult to guard against
> Allow NettyBufferPool to allocate heap buffers
> ----------------------------------------------
>
> Key: FLINK-18695
> URL: https://issues.apache.org/jira/browse/FLINK-18695
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Network
> Reporter: Chesnay Schepler
> Assignee: Yun Gao
> Priority: Major
> Fix For: 1.12.0
>
>
> in 4.1.43 netty made a change to their SslHandler to always use heap buffers
> for JDK SSLEngine implementations, to avoid an additional memory copy.
> However, our {{NettyBufferPool}} forbids heap buffer allocations.
> We will either have to allow heap buffer allocations, or create a custom
> SslHandler implementation that does not use heap buffers (although this seems
> ill-adviced?).
> /cc [~sewen] [~uce] [~NicoK] [~zjwang] [~pnowojski]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
