[
https://issues.apache.org/jira/browse/YARN-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563806#comment-15563806
]
Li Lu commented on YARN-5638:
-----------------------------
Thanks for the review [~sjlee0]!
bq. I see that the RM timestamp is currently the RM's cluster timestamp which
is really the start time of the RM process. And this is not the same as the
active state transition. Shouldn't we define the timestamp as when it became
active, rather than when the process started?
This was one major concern when I decided to use the rm's cluster timestamp.
However, we're regenerating cluster time stamp on each time
ResourceManager#startActiveServices is called. When a RM got a state transition
from active to standby, its activeServices will be set to null, so this will
force the RM to regenerate a new cluster timestamp on each time it becomes
active.
[~kasha], I saw you authored the original patch to re-generate RM cluster
timestamp on startActiveServices. Would you please help us to verify if RM's
clusterTimeStamp is a timestamp good enough to identify the currently active
RM? Thanks!
> Introduce a collector timestamp to uniquely identify collectors creation
> order in collector discovery
> -----------------------------------------------------------------------------------------------------
>
> Key: YARN-5638
> URL: https://issues.apache.org/jira/browse/YARN-5638
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Reporter: Li Lu
> Assignee: Li Lu
> Attachments: YARN-5638-trunk.v1.patch, YARN-5638-trunk.v2.patch,
> YARN-5638-trunk.v3.patch
>
>
> As discussed in YARN-3359, we need to further identify timeline collectors'
> creation order to rebuild collector discovery data in the RM. This JIRA
> proposes to use <rm_timestamp, logical_version_number> to order collectors
> for each application in the RM. This timestamp can then be used when a
> standby RM becomes active and rebuild collector discovery data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
