[
https://issues.apache.org/jira/browse/NIFI-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15436353#comment-15436353
]
Joseph Witt commented on NIFI-2660:
-----------------------------------
The suggested fix for this is here
https://github.com/apache/nifi/pull/930/commits/149e640b385e0f3a24fa9ab459295e5901eb34e6
Was planning to check that the class we're assigning was ConfigurableComponent
or Connectable but Connectable was not in framework-api so would need to
shuffle things around a bit and it would be a pretty weak protection anyway.
If something was passed in that was not one of those we'd be having to fall
back to the typical magic class loader and in reality not calling it properly
anyway.
> 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)
