[
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)
