[ https://issues.apache.org/jira/browse/YARN-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13636102#comment-13636102 ]
Bikas Saha commented on YARN-562: --------------------------------- The name clusterTimeStamp confuses me. What time is it? The use of that value is essentially and RM generation id or RM identifier. Currently we are using timestamp but tomorrow with HA we may have to move to a monotonically increasing number because machines may have time lag between them. So lets call it RMIdentifier or something like that. This also makes the NM code simpler to understand because we are saying containers come from the RM that has the same identifier as the RM currently connected to the NM. (which could be different RM's for different NM's if need be in the future). Secondly, I dont think the containerManager.setBlockNewContainerRequests(). We can simply invalidate the RMIdentifier in the resync thread where we are currently calling setBlockNewContainerRequests(true). The identifier matching code would reject all further containers. We dont need to remember to call setBlockNewContainerRequests(false) as the next registration will automatically set a new valid value for RMIdentifier. This will simply work as is for work preserving restart. Getting the value of RMIdentifier from NodeStatusUpdateImpl is not thread safe in the current patch. Instead of synchronized method we could simple use an AtomicLong if it exists. Or we could use a sychronized setter into ContainerManager to set the new value. This should be rare enough. > NM should reject containers allocated by previous RM > ---------------------------------------------------- > > Key: YARN-562 > URL: https://issues.apache.org/jira/browse/YARN-562 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager > Reporter: Jian He > Assignee: Jian He > Attachments: YARN-562.1.patch, YARN-562.2.patch, YARN-562.3.patch, > YARN-562.4.patch, YARN-562.5.patch, YARN-562.6.patch > > > Its possible that after RM shutdown, before AM goes down,AM still call > startContainer on NM with containers allocated by previous RM. When RM comes > back, NM doesn't know whether this container launch request comes from > previous RM or the current RM. we should reject containers allocated by > previous RM -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira