flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-7840) Shade Akka's Netty Dependency
Date Sun, 15 Oct 2017 17:40:00 GMT

    [ 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 <sewen@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)

Mime
View raw message