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

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

Github user NicoK commented on the issue:

    https://github.com/apache/flink/pull/4529
  
    FYI:
    - newer netty 4.0.xx versions also use `buffer.slice(index, length)` inside 
their `extractFrame()` method (see 
https://github.com/netty/netty/commit/891be30a28c6dc5a1edf1cb5a3690644cf4ff66e) 
and despite the comment on `extractFrame()`, this is also safe when used 
outside the `decode()` method as long as the buffer is retained (and then 
released later). By letting `NettyMessageDecoder` inherit from 
`LengthFieldBasedFrameDecoder` though, we also gain a smaller channel handler 
pipeline.
    - netty 4.1 offers an even improved `buffer.retainedSlice(index, length)` 
implementation (see 
https://github.com/netty/netty/commit/3a9f47216143082bdfba62e8940160856767d672) 
but we can't go that way yet due to our netty-router dependency


> avoid one additional buffer copy when receiving messages
> --------------------------------------------------------
>
>                 Key: FLINK-7428
>                 URL: https://issues.apache.org/jira/browse/FLINK-7428
>             Project: Flink
>          Issue Type: Improvement
>          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)

Reply via email to