Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 27 May 2016 23:03:13 +0000 (UTC)
From: "Sangjin Lee (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12973290.1464321287000.322227.1464390193005@Atlassian.JIRA>
In-Reply-To: <JIRA.12973290.1464321287000@Atlassian.JIRA>
References: <JIRA.12973290.1464321287000@Atlassian.JIRA> <JIRA.12973290.1464321287194@arcas>
Subject: [jira] [Commented] (YARN-5169) most YARN events have timestamp of
 -1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 27 May 2016 23:03:15 -0000


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

Sangjin Lee commented on YARN-5169:
-----------------------------------

bq. This is also my concern. For NMs, my hunch is we have much less events generated, therefore performance problem should be less severe?

IMO the JVM is past the point of developers having to worry about the performance of {{System.currentTimeMillis()}}. That may have been a legitimate concern 5 years ago, but probably not any longer, no?

> 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.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org