[jira] [Issue Comment Deleted] (MESOS-8826) ReaperProcess depends on clock manipulation.

["Gavin (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MESOS-8826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gavin updated MESOS-8826:
-------------------------
    Comment: was deleted

(was: www.rtat.net)

> ReaperProcess depends on clock manipulation.
> --------------------------------------------
>
>                 Key: MESOS-8826
>                 URL: https://issues.apache.org/jira/browse/MESOS-8826
>             Project: Mesos
>          Issue Type: Task
>          Components: libprocess
>            Reporter: Andrei Budnik
>            Priority: Major
>              Labels: integration, mesosphere
>
> After making composing containerizer as a default containerizer in tests by setting a value `mesos,docker` for `containerizers` flag in `MesosTest::CreateSlaveFlags()`, some tests started to endlessly wait for recovery completion after starting slave with paused clocks.
>  Recovery process for a docker c'zer uses `subprocess()` to spawn `docker ps -a` subprocess and [subscribes for its termination|https://github.com/apache/mesos/blob/ca21ca82071f2c53d5817424569977728260da65/src/docker/docker.cpp#L1466-L1467]. As a reaper process [uses `delay()`|https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/reap.cpp#L112], this leads to a hanging recovery process for the docker c'zer, when the libprocess' clocks are paused.
> A possible [solution might be|https://github.com/abudnik/mesos/commit/246958b8c942c150b2da778c8ab0f351be235992] using a single dedicated thread that doesn't use libprocess clocks and periodically iterates over pids and calls `waitpid` for each of them.
>  In addition, we can introduce one more dedicated thread that calls `waitpid(-1)` to wait for termination of children processes, so that we can get rid of
> {code:java}
> while (someEvent.isPending()) {
>   Clock::advance(process::MAX_REAP_INTERVAL());
>   Clock::settle();
> }{code}
> pattern in tests.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)