[
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: [email protected]
For additional commands, e-mail: [email protected]