[
https://issues.apache.org/jira/browse/FLINK-23147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17369348#comment-17369348
]
Arvid Heise commented on FLINK-23147:
-------------------------------------
Just to repeat what I have stated at other places: the intent of the plugin CL
is to only white-list API-related classes (it does a poor job with that), such
that we have a maximum separation of classes where only the API-related classes
are used, so that Flink can interact with the plugin in a meaningful way. So
naturally, no plugin should access {{ExecutorThreadFactory}}.
I think we both agree that we are not talking about plugins at all here. It's
more like a submodule of Flink that may (or may not) use the {{PluginLoader}}.
The main difference is that a plugin goes against an API (and we hide
everything else) and the submodule has access to everything, but adds
additional things only accessible to the submodule. In that regard, I'd either
implement a new {{Loader}} or make it very clear from the code-paths that the
submodule behaves differently. I'd not widen the scope and abilities of the
existing plugins (but I'd rather really limit access to classes). I think the
classloader of the submodule should also be implemented differently (always
trying to load from child first with no exception lists).
Btw and this orthogonal: adding a life-cycle to plugins would certainly ease
testing with MiniCluster and may unlock more use-cases. I think you already did
that with FLINK-23029.
> ThreadPools can be poisoned by context class loaders
> ----------------------------------------------------
>
> Key: FLINK-23147
> URL: https://issues.apache.org/jira/browse/FLINK-23147
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Coordination
> Reporter: Chesnay Schepler
> Priority: Major
> Fix For: 1.14.0
>
>
> Newly created threads in a thread pool inherit the context class loader (CCL)
> of the currently running thread.
> For thread pools this is very problematic because the CCL is unlikely to be
> reset at any point; not only can this leak another CL by accident, it can
> also cause class loading issues, for example when using a {{ServiceLoader}}
> because it relies on the CCL.
> With the scala-free runtime this for example means that if an actor system
> threads schedules something into future thread pool of the JM then a new
> thread is created which uses a plugin loader as a CCL. The plugin loaders are
> quite restrictive and prevent the loading of 3rd-party dependencies; so if
> the JM schedules something into the future thread pool which requires one of
> these dependencies to be accessible then we're gambling as to whether this
> dependency can actually be loaded in the end.
> Because it is difficult to ensure that we set the CCL correctly on all
> transitions from akka to Flink land I suggest to add a safeguard to the
> ExecutorThreadFactory to enforce that newly created threads are always
> initialized with the CL that has loaded Flink.
> /cc [~arvid] [~sewen]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
