[
https://issues.apache.org/jira/browse/FLINK-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378264#comment-16378264
]
ASF GitHub Bot commented on FLINK-7428:
---------------------------------------
Github user NicoK commented on the issue:
https://github.com/apache/flink/pull/4529
@zhijiangW looks like we're not upgrading the netty version in Flink 1.5 at
this stage due to the timing, i.e. too quite late in the development cycle. We
will do the upgrade after releasing Flink 1.5 so that we have enough time to
test it.
If you want to try out whether an upgrade changes anything for you, please
feel free to pull from #5571 and upgrade `flink-shaded-netty` in the root
`pom.xml` to `4.0.56.Final-3.0` once
[flink-shaded](https://github.com/apache/flink-shaded) 3.0 is released.
> avoid one additional buffer copy when receiving messages
> --------------------------------------------------------
>
> Key: FLINK-7428
> URL: https://issues.apache.org/jira/browse/FLINK-7428
> Project: Flink
> Issue Type: Sub-task
> Components: Network
> Affects Versions: 1.4.0
> Reporter: Nico Kruber
> Assignee: Nico Kruber
> Priority: Major
>
> By using {{LengthFieldBasedFrameDecoder}}, we create one unnecessary (netty)
> buffer copy in this class which could be easily avoided since we can ensure
> that the buffer is free to be released after decoding it in the
> {{NettyMessageDecoder}} and into our own buffer and/or events.
> The solution would be to make {{NettyMessageDecoder}} extend from
> {{LengthFieldBasedFrameDecoder}} and handle the decoding of the frames and
> the objects in there. In the frame creation otherwise done by
> {{LengthFieldBasedFrameDecoder}}, we could use a sliced buffer instead. This
> solution also makes the channel pipelines a bit simpler.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
