You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Haibo Chen (JIRA)" <ji...@apache.org> on 2017/03/08 18:27:38 UTC
[jira] [Commented] (YARN-5169) most YARN events have timestamp of
-1
[ https://issues.apache.org/jira/browse/YARN-5169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15901717#comment-15901717 ]
Haibo Chen commented on YARN-5169:
----------------------------------
[~sjlee0] [~gtCarrera9], IIUC from the above discussion, RM is already using System.currentTimeMillis() to generate ATS event timestamps, that means we are not worried about its performance overhead? If so, I think we should probably be consistent at least for events like container localization that we persist in ATS v2. Otherwise, YARN_NM_CONTAINER_LOCALIZATION_STARTED event will just show a timestamp of -1, which I don't think is of much value to users. Thoughts?
> most YARN events have timestamp of -1
> -------------------------------------
>
> Key: YARN-5169
> URL: https://issues.apache.org/jira/browse/YARN-5169
> Project: Hadoop YARN
> Issue Type: Bug
> Components: yarn
> Affects Versions: 2.7.2
> Reporter: Sangjin Lee
>
> Most of the YARN events (subclasses of {{AbstractEvent}}) have timestamp of -1. {{AbstractEvent}} have two constructors, one that initializes the timestamp to -1 and the other to the caller-provided value. But most events use the former (thus timestamp of -1).
> Some of the more common events, including {{ApplicationEvent}}, {{ContainerEvent}}, {{JobEvent}}, etc. do not set the timestamp.
> The rationale for this behavior seems to be mentioned in {{AbstractEvent}}:
> {code}
> // use this if you DON'T care about the timestamp
> public AbstractEvent(TYPE type) {
> this.type = type;
> // We're not generating a real timestamp here. It's too expensive.
> timestamp = -1L;
> }
> {code}
> This absence of the timestamp isn't really visible in many cases and therefore may have gone unnoticed, but the timeline service exposes this problem very visibly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org