[
https://issues.apache.org/jira/browse/YARN-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ming Ma updated YARN-1897:
--------------------------
Attachment: YARN-1897-7.patch
Thanks [~djp]!
bq. Number of preempted containers won't be count as container failure in AM
prospective and won't affect the success in application's running result.
Got it. Make sense to simulate it separately.
bq. If we want to emulate the case NM get shutdown (kill -9) suddenly and never
come back and its impact to RMContainers.
Interesting scenario. Yes, this simulation needs to be handled differently.
bq. I would prefer YARN-4131 to address 2nd sources event as an addendum to our
approach here. What do you think?
Sounds good. I have several questions about the implementations in YARN-4131
and can comment there.
Here is the updated patch that addresses the test results for
TestContainerManager. TestNetworkedJob failure isn't related.
> CLI and core support for signal container functionality
> -------------------------------------------------------
>
> Key: YARN-1897
> URL: https://issues.apache.org/jira/browse/YARN-1897
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: api
> Reporter: Ming Ma
> Assignee: Ming Ma
> Attachments: YARN-1897-2.patch, YARN-1897-3.patch, YARN-1897-4.patch,
> YARN-1897-5.patch, YARN-1897-6.patch, YARN-1897-7.patch, YARN-1897.1.patch
>
>
> We need to define SignalContainerRequest and SignalContainerResponse first as
> they are needed by other sub tasks. SignalContainerRequest should use
> OS-independent commands and provide a way to application to specify "reason"
> for diagnosis. SignalContainerResponse might be empty.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
