[
https://issues.apache.org/jira/browse/NIFI-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Witt resolved NIFI-2660.
-------------------------------
Resolution: Fixed
> 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)
