[
https://issues.apache.org/jira/browse/HADOOP-10070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13900639#comment-13900639
]
Daryn Sharp commented on HADOOP-10070:
--------------------------------------
+1 It's a good change, but I'm confused how it solves this problem. The
ConnectionId is based on addr, so the yarn connection should have already
created a new connection and used the principal from the second config -
although it would have continued using that principal for future connections
even if it changed? I think your patch solves the latter.
> RPC client doesn't use per-connection conf to determine server's expected
> Kerberos principal name
> -------------------------------------------------------------------------------------------------
>
> Key: HADOOP-10070
> URL: https://issues.apache.org/jira/browse/HADOOP-10070
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Affects Versions: 2.2.0
> Reporter: Aaron T. Myers
> Assignee: Aaron T. Myers
> Attachments: HADOOP-10070.patch, HADOOP-10070.patch,
> TestKerberosClient.java
>
>
> Currently, RPC client caches the {{Configuration}} object that was passed in
> to its constructor and uses that same conf for every connection it sets up
> thereafter. This can cause problems when security is enabled if the
> {{Configuration}} object provided when the first RPC connection was made does
> not contain all possible entries for all server principals that will later be
> used by subsequent connections. When this happens, it will result in later
> RPC connections incorrectly failing with the error "Failed to specify
> server's Kerberos principal name" even though the principal name was
> specified in the {{Configuration}} object provided on later RPC connection
> attempts.
> I believe this means that we've inadvertently reintroduced HADOOP-6907.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
