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 2017/10/15 17:40:00 UTC

[jira] [Commented] (FLINK-7840) Shade Akka's Netty Dependency

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

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

GitHub user StephanEwen opened a pull request:

    https://github.com/apache/flink/pull/4827

    [FLINK-7840] [build] Shade netty in akka

    ## What is the purpose of the change
    
    This change shade's Akka's dependency on Netty away.
    
    **Note:** Akka itself cannot be shaded away, there is some magic in Scala and annotations that Scala adds to preserve some compile time information, which make shading impossible (results in inconsistent code). That creates some problems.
    
    I tried several approaches to shading Akka's Netty:
    
    1. Add all Akka dependencies to `flink-runtime`. The dependencies disappear due to shading, but the classes are present in the same namespace.
      This leads to problems. For example, tests pull in the regular akka dependencies as well (transitively from `akka-testkit`) and for some reason it creates problems with the mixing of classes loaded from `flink-runtime` and `akka-actor`. One could fix that by adding all other akka dependencies as `provided` wherever `akka-testkit` is used.
      Similarly, users that want to use akka have to add their own dependency to akka and will get a similar clash of classes.
      This can be summed up as: Adding a dependency to a shaded jar (hence removing the dependency) without relocating the classes creates problems with dependency management.
    
      2. Add only `akka-remote` to the `flink-runtime` jar. That is the minimum we need to add to shade the Netty dependency. It softens the problem mentioned in (1), because only one of the akka dependencies is present in the `flink-runtime` jar, but it does not solve it completely.
    
    We shade all akka dependencies into the `flink-dist` jar anyways, so anyone running a job with Flink will need to set all its akka dependencies to `provided` and assume Flink's version anyways (reloading in a different classloader through child-first loading as a workaround aside).
    
    So from the user's perspective, akka is always provided. Child-first class loading can save the day for some users (allowing them to have a different akka version in the user code class loader than Flink has in the system class loader), but we should not strictly rely on that - its a pretty delicate thing.
    
    ## Brief change log
    
      - Set all akka compile time dependencies outside `flink-runtime` to *provided*.
      - Add `akka-remote_*` , `io.netty` and `org.uncommons.math` to the shaded `flink-runtime` jar
      - Relocate `org.jboss.netty` and `org.uncommons.math`
      - Add Netty as an explicit dependency to `flink-testutils` for the network proxy and shade it there as well.
      - Adds a check for unshaded Netty to the Travis CI script
    
    ## Verifying this change
    
      - The tests for this change pass on Travis.
      - One can simply test this by manually building the change and starting a simple standalone cluster and running one of the sample jobs.
    
    ## Does this pull request potentially affect one of the following parts:
    
      - Dependencies (does it add or upgrade a dependency): (yes / **no**): t removes dependencies
      - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: (yes / **no**)
      - The serializers: (yes / **no** / don't know)
      - The runtime per-record code paths (performance sensitive): (yes / **no** / don't know)
      - Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (**yes** / no / don't know): It affects akka which is used for communication and thus for failure detection.
    
    ## Documentation
    
      - Does this pull request introduce a new feature? (yes / **no**)
      - If yes, how is the feature documented? (**not applicable** / docs / JavaDocs / not documented)


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/StephanEwen/incubator-flink shade_akka_netty

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/flink/pull/4827.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #4827
    
----
commit 14eeb5b3f0bef73460e0c541381e0718cf71e641
Author: Stephan Ewen <se...@apache.org>
Date:   2017-10-13T23:49:26Z

    [FLINK-7840] [build] Shade netty in akka

----


> Shade Akka's Netty Dependency
> -----------------------------
>
>                 Key: FLINK-7840
>                 URL: https://issues.apache.org/jira/browse/FLINK-7840
>             Project: Flink
>          Issue Type: Improvement
>          Components: Build System
>            Reporter: Stephan Ewen
>            Assignee: Stephan Ewen
>             Fix For: 1.4.0
>
>
> In order to avoid clashes between different Netty versions we should shade Akka's Netty away.
> These dependency version clashed manifest themselves in very subtle ways, like occasional deadlocks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)