[ 
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)

Reply via email to