You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/02/23 08:45:00 UTC

[jira] [Commented] (FLINK-7428) avoid one additional buffer copy when receiving messages

    [ https://issues.apache.org/jira/browse/FLINK-7428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374081#comment-16374081 ] 

ASF GitHub Bot commented on FLINK-7428:
---------------------------------------

Github user zhijiangW commented on the issue:

    https://github.com/apache/flink/pull/4529
  
    Hey @NicoK , would this PR be covered in FLINK-1.5? We experienced the netty direct memory out of memory sometimes in production cased by `extractFrame`, so we expect this improvement. :)


> 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)