[
https://issues.apache.org/jira/browse/HADOOP-10070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897893#comment-13897893
]
Daryn Sharp commented on HADOOP-10070:
--------------------------------------
Will this completely fix the issue? Ex. Client1 uses a conf with a principal1
and establishes a connection. Client2 uses an equivalent conf with a different
principal. Unless the connection from client1 has closed, won't client2 reuse
the open connection? If correct, is this valid behavior in your case?
Truly fixing the problem requires a calculating equivalence of all keys that
affect the ipc client connection. Ideally the connectionId would consider all
"ipc.client.*" kvps predicated on the client only using values in that range
which may not be true. Extracting/calculating equivalence for just the subset
is likely not performant... Even serializing those keys back into another conf
key as a cached value would help but it'd need to updated if one of the cached
values changes which is back to re-checking all the keys. Sigh.
> 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)
