[
https://issues.apache.org/jira/browse/HADOOP-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100629#comment-13100629
]
Daryn Sharp commented on HADOOP-7510:
-------------------------------------
To address your concerns:
# You can use "mapreduce.job.hdfs-servers" to specify a list of paths for which
to get delegation tokens on the remote cluster.
2) The behavior is pretty well defined in the javadocs for InetAddress and
InetSocketAddress.
3) True, but are the other 205 changes not risky? The append code is risky,
the sync code is risky, the block receiver changes are risky, the lease renewal
changes are risky, etc. This are arguably more likely to fail in subtle ways,
whereas if the tokens don't match, the system flat out breaks.
I'm not sure I understand why you think I'm not using standard java apis. The
calls are all documented and the behavior is standard. I'm open to other means
of determining -exactly- what string was used to instantiate the
InetSocketAddress. In Java 7, it's called {{getHostString()}}.
How about if I add a config option to control whether the new behavior in this
patch is enabled?
> Tokens should use original hostname provided instead of ip
> ----------------------------------------------------------
>
> Key: HADOOP-7510
> URL: https://issues.apache.org/jira/browse/HADOOP-7510
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Fix For: 0.20.205.0
>
> Attachments: HADOOP-7510-2.patch, HADOOP-7510-3.patch,
> HADOOP-7510.patch
>
>
> Tokens currently store the ip:port of the remote server. This precludes
> tokens from being used after a host's ip is changed. Tokens should store the
> hostname used to make the RPC connection. This will enable new processes to
> use their existing tokens.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
