[
https://issues.apache.org/jira/browse/MAPREDUCE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13075991#comment-13075991
]
Daryn Sharp commented on MAPREDUCE-2764:
----------------------------------------
The renewal problem can be solved far more easily, w/o false coupling, and w/o
an assumption that hftp uses https. A DFS issues and renews tokens. The
problem is the lack of traceability from a token to its origin DFS. Setting a
DFS DT's service field to be the DFS uri, instead of ip:port, will allow a
trivial {{FileSystem.get}} to obtain the DFS. All guessing is removed, and the
hftp fs encapsulates that it's using https.
The RPC layer and the token selectors will require minor modification to use
the authority of the uri in the service field. The semantics of other tokens
should not be affected.
> 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
>
>
> 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
