> On Jan. 24, 2019, 4:41 p.m., Chun-Hung Hsiao wrote: > > src/tests/storage_local_resource_provider_tests.cpp > > Lines 3388 (patched) > > <https://reviews.apache.org/r/69781/diff/2/?file=2120346#file2120346line3404> > > > > IIUC the async loop you mentioned is the one trying to detect the > > creation of the domain socket, which is asynchronously called in > > `launchContainer`, so waiting for just this function to be dispatched might > > not be sufficient before pausing the clock again. How about waiting for > > `waitContainer` (to ensure that the post-start hook and thus the async loop > > has been finished) after `launchContainer` and before the pause? > > > > Alternatively, since this test doesn't actually care what happens after > > `launchContainer`, is it needed to resume the clock at all? > > Chun-Hung Hsiao wrote: > I believe it's because of some timers we used in, e.g., reaper or cgroup > to destroy the container. How about: > ``` > AWAIT_ASSERT_EQ(0, pluginKilled); > > // Resume the clock so the plugin container can be properly destroyed. > Clock::resume(); > > AWAIT_READY(pluginRestarted); > > Clock::pause(); > ``` > > Feel free to drop this. Gave you a ship-it. > > Chun-Hung Hsiao wrote: > Actually, let's just don't pause the clock again.
I went with your suggestion above, but explicitly bracketed the part requiring a running clock with `resume` and `pause`. This makes it a little clearer where exactly we need a running clock. - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/69781/#review212275 ----------------------------------------------------------- On Jan. 25, 2019, 10:28 a.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/69781/ > ----------------------------------------------------------- > > (Updated Jan. 25, 2019, 10:28 a.m.) > > > Review request for mesos and Chun-Hung Hsiao. > > > Bugs: MESOS-9130 > https://issues.apache.org/jira/browse/MESOS-9130 > > > Repository: mesos > > > Description > ------- > > While we addressed one source of flakiness of this test in > `2117f671c450d7c74edc53078e8c0ed6035020aa` we introduced a new source of > flakiness (agents send more than the expected number of > `UpdateSlaveMessage`s since they failed a timeout in registration with > the master). > > This patch ensures that the agent registers successfully before > continuing with the test. > > > Diffs > ----- > > src/tests/storage_local_resource_provider_tests.cpp > 164e93a3749d4d668e12de31641aecddddece384 > > > Diff: https://reviews.apache.org/r/69781/diff/3/ > > > Testing > ------- > > `make check` > > > Thanks, > > Benjamin Bannier > >
