> On July 9, 2016, 4:22 a.m., Zhitao Li wrote: > > src/master/master.cpp, lines 7602-7610 > > <https://reviews.apache.org/r/49844/diff/1/?file=1440271#file1440271line7602> > > > > Does the order of these two statements matter (e.g. we need ot ensure > > `subscribers.subscribed` always has the streamId in it before close)?
We emit a warning if the subscriber is not part of the `subscribers` map. Currently, it's part of a `defer()`, so it shouldn't matter. Are you alluding to the fact that it would be more _readable_ if we reorder these operations? - Anand ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/49844/#review141387 ----------------------------------------------------------- On July 9, 2016, 3:21 a.m., Anand Mazumdar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/49844/ > ----------------------------------------------------------- > > (Updated July 9, 2016, 3:21 a.m.) > > > Review request for mesos, Vinod Kone and Zhitao Li. > > > Bugs: MESOS-5812 > https://issues.apache.org/jira/browse/MESOS-5812 > > > Repository: mesos > > > Description > ------- > > This FD leak would only surface when running tests. We hold on to > a reference of the `Connection` object in the client so that it is > not destroyed before the connection is active. When running tests, > the IP:Port of libprocess remain the same which means the objects > keep on accumulating. In a real world cluster, we remove the > subscriber upon noticing a _disconnection_ i.e. this means the > socket has already been already closed upstream by Libprocess on > the server side. > > > Diffs > ----- > > src/master/master.hpp 845f2f6103b58e114dc5d50e3fcf70607c92a469 > src/master/master.cpp 79e3d78ba45060bc2f2532fdc3d105d1cc888d0f > > Diff: https://reviews.apache.org/r/49844/diff/ > > > Testing > ------- > > make check (gtest_repeat=1000) no FD leaks > > > Thanks, > > Anand Mazumdar > >
