Zhijie Shen commented on YARN-3836:

bq. I see that we're implementing the Comparable interface for all 3 types. I'm 
wondering if it makes sense for them. What would it mean to order 
TimelineEntity instances? Does it mean much? Where would it be useful? Do we 
need to implement it? The same questions go for the other 2 types...

For example, compareTo of TimelineEntity is used to order the entities in the 
return set of getEntities query. It would be better to return the entities 
ordered by timestamp instead of randomly.

bq. his is an open question. Is the id alone the identity or does the timestamp 
together form the identity? Do we expect users of TimelineEvent always be able 
to provide the timestamp? Honestly I'm not 100% sure what the contract is, and 
we probably want to make it explicit (and add it to the javadoc). Thoughts?

In ATS v1, we actually use id + timestamp to uniquely identify an event. On 
merit of doing this is to let the app to put the same event multiple times. For 
example, a job can request resource many times. Every time it can put a 
RESOURCE_REQUEST event with a unique timestamp and fill in the resource 

> add equals and hashCode to TimelineEntity and other classes in the data model
> -----------------------------------------------------------------------------
>                 Key: YARN-3836
>                 URL: https://issues.apache.org/jira/browse/YARN-3836
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>    Affects Versions: YARN-2928
>            Reporter: Sangjin Lee
>            Assignee: Li Lu
>         Attachments: YARN-3836-YARN-2928.001.patch
> Classes in the data model API (e.g. {{TimelineEntity}}, 
> {{TimelineEntity.Identifer}}, etc.) do not override {{equals()}} or 
> {{hashCode()}}. This can cause problems when these objects are used in a 
> collection such as a {{HashSet}}. We should implement these methods wherever 
> appropriate.

This message was sent by Atlassian JIRA

Reply via email to