[
https://issues.apache.org/jira/browse/FLINK-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182715#comment-16182715
]
ASF GitHub Bot commented on FLINK-7428:
---------------------------------------
Github user NicoK commented on the issue:
https://github.com/apache/flink/pull/4529
I haven't had time to test this yet - I doubt that this is simply solved by
using our memory segments but I need to understand the problem better.
Maybe this also goes away with [flow
control](https://issues.apache.org/jira/browse/FLINK-7282) being added since
then we have more control over what the sender sends and can make sure that we
have enough buffers to process its data.
> 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
>
> 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
(v6.4.14#64029)
