[
https://issues.apache.org/jira/browse/YARN-4700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15170387#comment-15170387
]
Varun Saxena commented on YARN-4700:
------------------------------------
If we do not fix it in RM, as was the conclusion in those 2 JIRAs' and we use
current timestamp, we will have to peek into the app table to see if the app
already exists or not and if yes, do not enter in activity table.
The reason as it seems from the discussion on those JIRAs' is that ATS events
are asynchronous(because we use a dispatcher in between) so its better to
replay the events.
Maybe we can give priority to app start and finish events and make it
synchronous for V2 as the app collector will be running within RM but this
would block app finishing till ATS event completes.
> ATS storage has one extra record each time the RM got restarted
> ---------------------------------------------------------------
>
> Key: YARN-4700
> URL: https://issues.apache.org/jira/browse/YARN-4700
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Affects Versions: YARN-2928
> Reporter: Li Lu
> Assignee: Naganarasimha G R
> Labels: yarn-2928-1st-milestone
>
> When testing the new web UI for ATS v2, I noticed that we're creating one
> extra record for each finished application (but still hold in the RM state
> store) each time the RM got restarted. It's quite possible that we add the
> cluster start timestamp into the default cluster id, thus each time we're
> creating a new record for one application (cluster id is a part of the row
> key). We need to fix this behavior, probably by having a better default
> cluster id.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
