Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FLINK-8768][network] Let NettyMessageDecoder inherit from LengthFieldBasedFrameDecoder #5570

Closed
wants to merge 1 commit into from

Conversation

NicoK
Copy link
Contributor

@NicoK NicoK commented Feb 23, 2018

What is the purpose of the change

Instead of being two steps in the channel pipeline, NettyMessageDecoder could derive from LengthFieldBasedFrameDecoder to reduce overhead and give us more control over the protocol.

As a first step, we will use this to override the #extractFrame() method to restore the old Netty 4.0.27 behaviour for non-credit based code paths which had a bug with Netty >= 4.0.28 (see FLINK-8759).

Brief change log

  • make NettyMessageDecoder inherit from LengthFieldBasedFrameDecoder (beware that this changes the decoder from a MessageToMessageDecoder to a ByteToMessageDecoder with different cleanup invariants!)

Verifying this change

This change is already covered by existing tests, such as NettyMessageSerializationTest or other network tests using the encoding/decoding pipeline.

Does this pull request potentially affect one of the following parts:

  • Dependencies (does it add or upgrade a dependency): no
  • The public API, i.e., is any changed class annotated with @Public(Evolving): no
  • The serializers: no
  • The runtime per-record code paths (performance sensitive): no (only per buffer)
  • Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: no
  • The S3 file system connector: no

Documentation

  • Does this pull request introduce a new feature? no
  • If yes, how is the feature documented? (JavaDocs)

Copy link
Contributor

@pnowojski pnowojski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm % dead code

* </pre>
*/
static class NettyMessageDecoder extends LengthFieldBasedFrameDecoder {
private final boolean restoreOldNettyBehaviour;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

drop the unused field?

@@ -44,10 +44,11 @@
*/
public class NettyMessageSerializationTest {

public static final boolean RESTORE_OLD_NETTY_BEHAVIOUR = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dead code ;)

…dBasedFrameDecoder

This replaces one additional step from the pipeline and does not only remove
overhead there but also allows use to override the #extractFrame() method to
restore the old Netty 4.0.27 behaviour for non-credit based code paths which
had a bug with Netty >= 4.0.28 there (see FLINK-8759).
@NicoK
Copy link
Contributor Author

NicoK commented Feb 28, 2018

ok, done

Copy link
Contributor

@tillrohrmann tillrohrmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good. Thanks for the contribution @NicoK and the review @pnowojski. Merging this PR.

tillrohrmann pushed a commit to tillrohrmann/flink that referenced this pull request Jun 12, 2018
…dBasedFrameDecoder

This replaces one additional step from the pipeline and does not only remove
overhead there but also allows use to override the #extractFrame() method to
restore the old Netty 4.0.27 behaviour for non-credit based code paths which
had a bug with Netty >= 4.0.28 there (see FLINK-8759).

This closes apache#5570.
@asfgit asfgit closed this in fd5b680 Jun 12, 2018
pnowojski pushed a commit to dataArtisans/flink that referenced this pull request Jun 29, 2018
…dBasedFrameDecoder

This replaces one additional step from the pipeline and does not only remove
overhead there but also allows use to override the #extractFrame() method to
restore the old Netty 4.0.27 behaviour for non-credit based code paths which
had a bug with Netty >= 4.0.28 there (see FLINK-8759).

This closes apache#5570.
NicoK pushed a commit to dataArtisans/flink that referenced this pull request Jul 9, 2018
…dBasedFrameDecoder

This replaces one additional step from the pipeline and does not only remove
overhead there but also allows use to override the #extractFrame() method to
restore the old Netty 4.0.27 behaviour for non-credit based code paths which
had a bug with Netty >= 4.0.28 there (see FLINK-8759).

This closes apache#5570.
NicoK pushed a commit to dataArtisans/flink that referenced this pull request Jul 9, 2018
…dBasedFrameDecoder

This replaces one additional step from the pipeline and does not only remove
overhead there but also allows use to override the #extractFrame() method to
restore the old Netty 4.0.27 behaviour for non-credit based code paths which
had a bug with Netty >= 4.0.28 there (see FLINK-8759).

This closes apache#5570.
sampathBhat pushed a commit to sampathBhat/flink that referenced this pull request Jul 26, 2018
…dBasedFrameDecoder

This replaces one additional step from the pipeline and does not only remove
overhead there but also allows use to override the #extractFrame() method to
restore the old Netty 4.0.27 behaviour for non-credit based code paths which
had a bug with Netty >= 4.0.28 there (see FLINK-8759).

This closes apache#5570.
NicoK pushed a commit that referenced this pull request Jan 24, 2019
…dBasedFrameDecoder

This replaces one additional step from the pipeline and does not only remove
overhead there but also allows use to override the #extractFrame() method to
restore the old Netty 4.0.27 behaviour for non-credit based code paths which
had a bug with Netty >= 4.0.28 there (see FLINK-8759).

This closes #5570.

Signed-off-by: Nico Kruber <nico@data-artisans.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants