[
https://issues.apache.org/jira/browse/YARN-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643085#comment-14643085
]
zhihai xu commented on YARN-3965:
---------------------------------
thanks for the explanation [~zhiguohong]!
bq. One option is to make nmStartupTime as a non-static filed of NMContext. But
I doubt is it worth to make simple thing complecated. BTW, the startup
timestampt of ResourceManager is also static.
Thanks for the information, Since time stamp of ResourceManager is also static,
I am ok to use static. In practice, there is only one active RM and many active
NMs. Adding nmStartupTime to NMContext is not bad, which can provide more
information about the NM in the context. So either static or non-static is ok
to me. Let's see what other people's opinions are.
If we use static, Can we add an API to get the time stamp for NM similar as
ResourceManager.getClusterTimeStamp for RM?
bq. It's "final" so don't need warry about that
Yes, you are right. I missed "final" keywords
> Add starup timestamp for nodemanager
> ------------------------------------
>
> Key: YARN-3965
> URL: https://issues.apache.org/jira/browse/YARN-3965
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: nodemanager
> Reporter: Hong Zhiguo
> Assignee: Hong Zhiguo
> Priority: Minor
> Attachments: YARN-3965-2.patch, YARN-3965.patch
>
>
> We have startup timestamp for RM already, but don't for NM.
> Sometimes cluster operator modified configuration of all nodes and kicked off
> command to restart all NMs. He found out it's hard for him to check whether
> all NMs are restarted. Actually there's always some NMs didn't restart as he
> expected, which leads to some error later due to inconsistent configuration.
> If we have startup timestamp for NM, the operator could easily fetch it via
> NM webservice and find out which NM didn't restart, and take mannaul action
> for it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
