[
https://issues.apache.org/jira/browse/NIFI-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15959435#comment-15959435
]
ASF subversion and git services commented on NIFI-3520:
-------------------------------------------------------
Commit 556f309df086fefdcc6ca717294eaa91d3a4e113 in nifi's branch
refs/heads/master from [~bbende]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=556f309 ]
NIFI-3520 Refactoring instance class loading
- Fixing FlowController to use appropriate class loader when instantiating
processor
- Updating ExtensionManager to leverage new flag in MANIFEST from NAR plugin
- Adding ReloadComponent interface and refactoring instance class loading to
use it
- Fixing FetchHDFS issue with TDE by using ugi.doAs
- Refactoring nifi-nar-utils so that ExtensionManager only lives in
nifi-framework
- Caching temp components found during service loader in ExtensionManager
- Updating authorizables, docs, and fingerprinting to use the cached components
- Introducing a flag on @RequiresInstanceClassLoading to indicate if ancestor
resources should be cloned
- Updating developer guide regarding cloneAncestorResources flag
- This closes #1635
> HDFS processors experiencing Kerberos "impersonate" errors
> -----------------------------------------------------------
>
> Key: NIFI-3520
> URL: https://issues.apache.org/jira/browse/NIFI-3520
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.0.0, 1.1.0, 1.1.1, 1.0.1
> Reporter: Jeff Storck
> Assignee: Bryan Bende
> Fix For: 1.2.0
>
>
> When multiple Kerberos principals are used between multiple HDFS processors,
> the processor instances will be able to login to Kerberos with their
> configured principals initially, but will not properly relogin.
> For example, if there are two PutHDFS processors, one configured as
> us...@example.com, and the other as us...@example.com, they will both login
> with the KDC correctly and be able to transfer files to HDFS. Once one of
> the PutHDFS processors attempts to relogin, it may end up being logged in as
> the principal from the other PutHDFS processor. The principal contexts end
> up getting switched, and the hadoop client used by the processor will attempt
> to proxy requests from one user through another, resulting in the following
> exception:
> {panel}Failed to write to HDFS due to
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.authorize.AuthorizationException):
> User: us...@example.com is not allowed to impersonate
> us...@example.com{panel}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
