Chesnay Schepler created FLINK-23147:
----------------------------------------
Summary: 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
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)
