hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jitendra Nath Pandey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-2764) Fix renewal of dfs delegation tokens
Date Fri, 05 Aug 2011 22:24:27 GMT

    [ https://issues.apache.org/jira/browse/MAPREDUCE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080263#comment-13080263

Jitendra Nath Pandey commented on MAPREDUCE-2764:

I had a long discussion with Owen. Here is the new proposal:

- Add setKind method in the token
- Add a new kind for tokens i.e. HFTP
- HftpFileSystem client fetches the token and sets the kind to HFTP and the service to ip:http-port.
- Renewer determines the filesystem to use (hftp or DFS) using the kind of the token. The
hftp port is also obtained from the token.
- Hftp client looks for HFTP tokens in the UGI when making an hftp call to nn.
- Hftp client sends the token in the url to the namenode. Before serializing the token in
the url, Hftp client changes the service to ip:rpc-port and kind of the token back to HDFS.

  No change to Namenode.
  No change to rpc.
  No change to token selectors.
  Most of the changes are confined to HftpFileSystem class.
  HftpFilesystem already has a mechanism to map the http port to rpc port, which it can use
to set the service before encoding the token in the url.
  Changing the kind will make sure that this token is not accidentally used for rpc connection.

  Token obtained over hftp, cannot be used over rpc by clients.

> 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:
>         Attachments: MAPREDUCE-2764.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


View raw message