> On May 21, 2018, 1:21 p.m., Qian Zhang wrote: > > Can you please explain how the container will be cleaned up from the > > `containers_` map after agent recovery? > > Andrei Budnik wrote: > In the current implementation, a recovered container can be cleaned up > only when someone calls `destroy()`. I didn't change that behaviour. > > Qian Zhang wrote: > So if no one calls `destroy()` on a recovered container (e.g., it just > terminates itself), the container will never be cleaned up from the > `containers_` map which seems a memory leak. I know you did not change that > behaviour, but I think it is a tech debt which we need to fix.
Fixed. - Andrei ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66668/#review203490 ----------------------------------------------------------- On April 17, 2018, 3:23 p.m., Andrei Budnik wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/66668/ > ----------------------------------------------------------- > > (Updated April 17, 2018, 3:23 p.m.) > > > Review request for mesos, Alexander Rukletsov, Greg Mann, Jie Yu, and Qian > Zhang. > > > Bugs: MESOS-8712 > https://issues.apache.org/jira/browse/MESOS-8712 > > > Repository: mesos > > > Description > ------- > > Previously, we stored `destroyed` promise for each container and used > it to guarantee that `destroy()` returns a non-empty value when the > destroy-in-progress stops an launch-in-progress using the next > containerizer. Since `wait()` and `destroy()` return the same > `ContainerTermination` value when called with the same ContainerID > argument, we can remove `destroyed` promise and add callbacks to > clean up `containers_` map instead. > > > Diffs > ----- > > src/slave/containerizer/composing.cpp > 1fb79f53b48154ecbd3b0165b6a8002c871e6dce > > > Diff: https://reviews.apache.org/r/66668/diff/8/ > > > Testing > ------- > > internal CI > > > Thanks, > > Andrei Budnik > >
