[
https://issues.apache.org/jira/browse/YARN-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306346#comment-14306346
]
Zhijie Shen commented on YARN-3144:
-----------------------------------
Getting the timeline delegation token is only invoked in case that the
configuration indicates that the timeline service is enabled. As the timeline
server is not the always-up daemon like RM/NM, such that we have this config to
indicate the timeline service has been setup for this cluster. It seems more
like a misconfiguration issue.
I think it makes sense when the timeline server is up, the user still don't
need to get a timeline delegation token, because the application will never use
it. In this case, getting the DT doesn't harm (unless the request fails). On
the other side, if the app really needs the DT to posting timeline data to the
server, isn't it better to fail early instead of at runtime? For job history
server, we did similar thing in YARNRunner.
For the connection refused scenario, I think the proper approach is to fix the
communication channel to be more stable, though returning null instead of
through exception may be quick work around to suppress the issue given not may
apps are using the service now.
> Configuration for making delegation token failures to timeline server
> not-fatal
> -------------------------------------------------------------------------------
>
> Key: YARN-3144
> URL: https://issues.apache.org/jira/browse/YARN-3144
> Project: Hadoop YARN
> Issue Type: Improvement
> Reporter: Jonathan Eagles
> Assignee: Jonathan Eagles
> Attachments: YARN-3144.1.patch
>
>
> Posting events to the timeline server is best-effort. However, getting the
> delegation tokens from the timeline server will kill the job. This patch adds
> a configuration to make get delegation token operations "best-effort".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
