[
https://issues.apache.org/jira/browse/NIFI-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15436930#comment-15436930
]
ASF subversion and git services commented on NIFI-2660:
-------------------------------------------------------
Commit 1745c1274b274a994a92312054d8951ce1c499d0 in nifi's branch
refs/heads/master from [~joewitt]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=1745c12 ]
NIFI-2608 This closes #930. restructured the ConsumeKafka processor to follow
new consumer API. Made nar classloading more precise to support spawned threads
NIFI-2660.
> 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)
