[
https://issues.apache.org/jira/browse/MAPREDUCE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094759#comment-13094759
]
Nathan Roberts commented on MAPREDUCE-2764:
-------------------------------------------
bq. It seems to make much more sense to separate the HFTP tokens out and use
the service field to refer to the HFTP address, in the way it was intended to
be used.
Can you say a little about what the service field was intended to do? What I'm
stuck on is that the client is going to authenticate with the remote NN and get
back an HFTP token with an HFTP address in the service field, but then that
same token is going to eventually get to a remote DN that needs to use it to
talk to the NN via RPC. What am I not understanding?
> Fix renewal of dfs delegation tokens
> ------------------------------------
>
> Key: MAPREDUCE-2764
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2764
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Fix For: 0.20.205.0
>
> Attachments: MAPREDUCE-2764-2.patch, MAPREDUCE-2764.patch,
> delegation.patch
>
>
> The JT may have issues renewing hftp tokens which disrupt long distcp jobs.
> The problem is the JT's delegation token renewal code is built on brittle
> assumptions. The token's service field contains only the "ip:port" pair.
> The renewal process assumes that the scheme must be hdfs. If that fails due
> to a {{VersionMismatchException}}, it tries https based on another assumption
> that it must be hftp if it's not hdfs. A number of other exceptions, most
> commonly {{IOExceptions}}, can be generated which fouls up the renewal since
> it won't fallback to https.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
