Joseph Witt created NIFI-2660:
---------------------------------
Summary: Classloader isolation not tight enough for libraries that
spawn threads
Key: NIFI-2660
URL: https://issues.apache.org/jira/browse/NIFI-2660
Project: Apache NiFi
Issue Type: Bug
Components: Core Framework
Reporter: Joseph Witt
Assignee: Joseph Witt
Priority: Critical
Fix For: 1.0.0
The framework now has pretty much all entry points to components covered via a
nice NarCloseable construct. However, it is always being set to use the
NarThreadContextClassLoader as the set context class loader. This is good in
that it means the specific Nar class loader will be found for classes created
by those threads since they remain in the call stack and the
NarThreadContextClassLoader can then rehome them to their nar. This is bad
though when those libraries spawn threads before we ever end up changing the
classloader to the nar specific classloader as those threads will have nothing
in their callstack that leads them back to the specific nar.
This was found while testing parallel usage of the Kafka 0.9 and Kafka 0.10
client processors. I could run one of them at a time but not another. In
Kafka's code it is clear where they try to properly use the context class
loader. So in debugging found that we were in their thread but still not
jailed to the proper Nar specific class loader which means game over as their
call stacks won't hit. Therefore, rather than setting everything to the
generic 'find it later' classloader we should instead use this NarCloseable
construct but have it directly jailed to the NarClassLoader of the component in
question.
This is likely to be addressed in the commits for NIFI-2608/PR-930.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
