Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-issues@hadoop.apache.org
Date: Wed, 31 Aug 2011 23:17:10 +0000 (UTC)
From: "Nathan Roberts (JIRA)" <jira@apache.org>
To: mapreduce-issues@hadoop.apache.org
Message-ID: 
 <1663029876.4981.1314832630196.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1887929704.321.1312247667217.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (MAPREDUCE-2764) Fix renewal of dfs delegation
 tokens
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Nathan Roberts commented on MAPREDUCE-2764:
-------------------------------------------

Thanks Owen. Getting closer.

.bq Given that 203 and 204 are in production, we can't make incompatible changes, therefore the HFTP service needs to continue to send and receive HDFS delegation tokens. 

Definitely agree on the compatibility requirement.

.bq Therefore, having the HFTP client manipulate the tokens into the form that should have been sent seems like the best alternative.

Where am I going wrong in this use case:
* I launch an MR job from a client box
* As part of this launch, the client will authenticate with all the required NNs and gather up all the necessary delegation tokens. Prior to serializing the credentials, the HFTP client would have already manipulated any tokens it has received into something like (kind=hftp, service=host/hftp_port)
* There will be 2 uses of the token when read later from the credentials.
*# The JT will want to renew it (so it needs HFTP host/port information, so far so good). 
*# The map task might use it to fetch data from the remote cluster (it can talk to the remote namenode fine but doesn't it need the HDFS host/port information to pass to the servlet running on the datanode that will serve up the file's contents? Since this information is no longer associated with this token, how will it be able to do this?)


> 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