[
https://issues.apache.org/jira/browse/NIFI-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15951345#comment-15951345
]
ASF GitHub Bot commented on NIFI-3520:
--------------------------------------
Github user mcgilman commented on the issue:
https://github.com/apache/nifi/pull/1635
@bbende The code changes look good. However, I think the implication of the
using the `RequiresInstanceClassLoading` annotation with the
`cloneDuringInstanceClassLoading` flag on an NAR could lead to some confusing
deployments. I think the confusion will come from the fact that the flag on the
NAR will only be honored when the entire chain from the component that
`RequiresInstanceClassLoading` is also flagged. Rather than trying to identify
cases that could be problematic like forgetting the flag in a NAR in the chain
or setting the flag on a NAR that contains a service API, should we investigate
a way to automatically clone when possible?
> 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)
