----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66931/#review202409 -----------------------------------------------------------
src/tests/resource_provider_manager_tests.cpp Lines 1132 (patched) <https://reviews.apache.org/r/66931/#comment284226> This action will be invoked in the Driver's context. Could you explain why this could happen? src/tests/resource_provider_manager_tests.cpp Line 1140 (original), 1146 (patched) <https://reviews.apache.org/r/66931/#comment284227> Instead of creating a new mock resource provider, could we restart the agent with the same pid, and let the same mock resource provider to subscribe to the new agent? Feel free to drop this if you have concerns with this approach. - Chun-Hung Hsiao On May 3, 2018, 11:46 a.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/66931/ > ----------------------------------------------------------- > > (Updated May 3, 2018, 11:46 a.m.) > > > Review request for mesos, Chun-Hung Hsiao and Jan Schlicht. > > > Bugs: MESOS-8874 > https://issues.apache.org/jira/browse/MESOS-8874 > > > Repository: mesos > > > Description > ------- > > We previously did not make ensure that after the simulated agent > failover in > `ResourceProviderManagerHttpApiTest.ResubscribeResourceProvider` the > mock resource provider created as part of the test did not reconnect > to the restarted agent (as opposed to the newly initialized resource > provider). This lead to unmet test expectations. > > With this patch we now explicitly tear down the mock resource provider > after we have detected that the agent went away to prevent the race. > > > Diffs > ----- > > src/tests/resource_provider_manager_tests.cpp > e8ca377fd0a927b99fdaf6a8ee0139025a41298e > > > Diff: https://reviews.apache.org/r/66931/diff/1/ > > > Testing > ------- > > `make check` > > Ran the test repeatedly under high system load without triggering the issue > again with this patch. > > > Thanks, > > Benjamin Bannier > >
