[jira] [Commented] (MAPREDUCE-2764) Fix renewal of dfs delegation tokens

["Yongjun Zhang (JIRA)" <ji...@apache.org>]

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

Yongjun Zhang commented on MAPREDUCE-2764:
------------------------------------------

HI [~owen.omalley],

Thanks for your earlier work here. I have some questions, appreciate your time to answer, and hope I'm not taxing your memory too much because it has been quite long since this jira was resolved.

279	  private synchronized TokenRenewer getRenewer() throws IOException {
280	    if (renewer != null) {
281	      return renewer;
282	    }
283	    renewer = TRIVIAL_RENEWER;
284	    for (TokenRenewer canidate: renewers) {
285	      if (canidate.handleKind(this.kind)) {
286	        renewer = canidate;
287	        return renewer;
288	      }
289	    }
290	    LOG.warn("No TokenRenewer defined for token kind " + this.kind);
291	    return renewer;
292	  }

If the loop to find a candicate failes, we would be using TRIVIAL_RENEWER, whose {{isManaged()}} method returns false. When this happens, it means YARN will not try to renew the token. Is this intended?

I have a distcp case that I was hoping I could let distcp to pass an HDFS token with null renewer to YARN because I don't want YARN to renew the token. However,  looks like the above loop will always find a candicate renewer, thus the TRIVIAL_RENEWER will not be used. Is this expected?

Any suggestion on how to let YARN not to renew a token and let the client handle renewal? 

I guess the current way how YARN works is to always try to renew the job token before scheduling the job, to avoid invalid token to begin with (right?), then when the TRIVIAL_RENEWER will be used in the above code? Why the above method does return failure if it can't find a matching renewer (instead, it uses TRIVIAL_RENEWER)?

Sorry for quite a few questions, thanks again for your time!




> 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: Owen O'Malley
>             Fix For: 0.20.205.0, 0.23.0, 0.24.0
>
>         Attachments: MAPREDUCE-2764-2.patch, MAPREDUCE-2764-3.patch, MAPREDUCE-2764-4.patch, MAPREDUCE-2764-trunk.patch, MAPREDUCE-2764-trunk.patch, MAPREDUCE-2764-trunk.patch, MAPREDUCE-2764.patch, delegation.patch, token-renew-trunk.patch, token-renew.patch, token-renew.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 was sent by Atlassian JIRA
(v6.3.4#6332)