mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jpe...@apache.org>
Subject Re: Review Request 66259: Added `max_completion_time` support to command executor.
Date Fri, 13 Apr 2018 17:23:01 GMT

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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message