A {@link PreemptionMessage} is part of the RM-AM protocol, and it is used bythe RM to specify resources that the RM wants to reclaim from this ApplicationMaster
(AM). The AM receives a {@link StrictPreemptionContract} message encoding which containers the platform mayforcibly kill, granting it an opportunity to checkpoint state or adjust its execution plan. The message may also include a {@link PreemptionContract}granting the AM more latitude in selecting which resources to return to the cluster.
The AM should decode both parts of the message. The {@link StrictPreemptionContract} specifies particular allocations that the RMrequires back. The AM can checkpoint containers' state, adjust its execution plan to move the computation, or take no action and hope that conditions that caused the RM to ask for the container will change.
In contrast, the {@link PreemptionContract} also includes a description ofresources with a set of containers. If the AM releases containers matching that profile, then the containers enumerated in {@link PreemptionContract#getContainers()} may not be killed.
Each preemption message reflects the RM's current understanding of the cluster state, so a request to return
The policy enforced by the RM is part of the scheduler. Generally, only containers that have been requested consistently should be killed, but the details are not specified.
|
|
|
|
|
|
|
|
|
|
|
|