[
https://issues.apache.org/jira/browse/YARN-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tsuyoshi OZAWA updated YARN-2052:
---------------------------------
Attachment: YARN-2052.3.patch
[~jianhe], thank you for the comment.
{code}
Application itself may possibly use Container.getId to differentiate the
containers, two containers allocated by two RMs may have the same id integer,
then the application logic will break. will this be fine?
{code}
Good point. Added doc to {{ContainerId#getId}}. In addition to it, implemented
{{compareTo}} and {{equals}} to distinguish containers. I think this
alternative is acceptable. What do you think?
BTW, I think we should update CheckpointAMPreemptionPolicy after this JIRA.
{code}
Collections.sort(listOfCont, new Comparator<Container>() {
@Override
public int compare(final Container o1, final Container o2) {
return o2.getId().getId() - o1.getId().getId();
}
});
{code}
> ContainerId creation after work preserving restart is broken
> ------------------------------------------------------------
>
> Key: YARN-2052
> URL: https://issues.apache.org/jira/browse/YARN-2052
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: resourcemanager
> Reporter: Tsuyoshi OZAWA
> Assignee: Tsuyoshi OZAWA
> Attachments: YARN-2052.1.patch, YARN-2052.2.patch, YARN-2052.3.patch
>
>
> Container ids are made unique by using the app identifier and appending a
> monotonically increasing sequence number to it. Since container creation is a
> high churn activity the RM does not store the sequence number per app. So
> after restart it does not know what the new sequence number should be for new
> allocations.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
