-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66259/#review201112
-----------------------------------------------------------




src/launcher/executor.cpp
Lines 590 (patched)
<https://reviews.apache.org/r/66259/#comment282096>

    I think that it makes more sense to move this block to just before we call 
`launchTaskSubprocess`.
    
    I wonder whether we should also make the log message show `Starting task 
$TASKID with maximum completion time of $DURATION`?



src/launcher/executor.cpp
Lines 750 (patched)
<https://reviews.apache.org/r/66259/#comment282093>

    Move this into the `if` above



src/launcher/executor.cpp
Lines 936 (patched)
<https://reviews.apache.org/r/66259/#comment282092>

    Should set maxCompletionTimer to `None()` as well, for consistency.



src/launcher/executor.cpp
Lines 1008 (patched)
<https://reviews.apache.org/r/66259/#comment282097>

    Can `pid` ever be validly `None()` due to your changes? If it can, I'm not 
seeing the reason ...



src/launcher/executor.cpp
Lines 1036 (patched)
<https://reviews.apache.org/r/66259/#comment282089>

    How about calling this `taskCompletionTimeout`?



src/launcher/executor.cpp
Lines 1037 (patched)
<https://reviews.apache.org/r/66259/#comment282094>

    Consider adding a `CHECK(!killed)` here, since we should never do 
completion time handling after receiving a scheduler kill.



src/launcher/executor.cpp
Lines 1038 (patched)
<https://reviews.apache.org/r/66259/#comment282095>

    I think this can be a `CHECK(!terminated)` since you cancel the completion 
timeout in `reaped()`.



src/launcher/executor.cpp
Lines 1043 (patched)
<https://reviews.apache.org/r/66259/#comment282090>

    Suggest that we phrase this more naturally:
    ```
    Killing task $TASKID which exceeded its maximum completion time
    ```
    
    I'm assuming that you wanted to depend on the log message in `escalated` to 
capture the completion time?



src/launcher/executor.cpp
Lines 1049 (patched)
<https://reviews.apache.org/r/66259/#comment282099>

    What happens if the scheduler sends a `kill` after the completion timeout 
fires? In this code, it seems like the `kill` will still be processed; there is 
also some inconsistency because we are killing the task but don't set the 
`killed` flag.
    
    Maybe a better approach would be to call `kill()` from here with a 0 grace 
period? Then in `kill()` I'd argue that a 0 grace period should skip the 
`SIGTERM` phase.


- James Peach


On April 8, 2018, 12:51 a.m., Zhitao Li wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66259/
> -----------------------------------------------------------
> 
> (Updated April 8, 2018, 12:51 a.m.)
> 
> 
> Review request for mesos, Jason Lai and James Peach.
> 
> 
> Bugs: MESOS-8725
>     https://issues.apache.org/jira/browse/MESOS-8725
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> If `TaskInfo.max_completion_time` is set, command executor will kill
> the task with `SIGKILL` immediately. Note that no KillPolicy will be
> observed. Framework should only received a `TASK_FAILED` state with
> `REASON_MAX_COMPLETION_TIME_REACHED` reason.
> 
> 
> Diffs
> -----
> 
>   src/launcher/executor.cpp 8d0869cfcdfc693301d0e185a036e97204bad17f 
> 
> 
> Diff: https://reviews.apache.org/r/66259/diff/4/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Zhitao Li
> 
>

Reply via email to