----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/39548/#review103710 -----------------------------------------------------------
src/tests/scheduler_tests.cpp (lines 999 - 1008) <https://reviews.apache.org/r/39548/#comment161781> Wondering, why did you change order here i.e. move this piece of code up ? Now, with using `FUTURE_DISPATCH` you can gurrantee that `Suppress` would be completed before the `Clock` is advanced. Am I missing something ? src/tests/scheduler_tests.cpp (line 1007) <https://reviews.apache.org/r/39548/#comment161783> This alone won't suffice. AFAIK, the `Future` returned by `FUTURE_DISPATCH` is marked ready when the function is invoked not neccessarily when the function has completely executed. You would want to pause/settle the clock too. The modified code would look like: ``` Future<Nothing> suppressOffers = FUTURE_DISPATCH(_, &MesosAllocatorProcess::suppressOffers); { Call call; call.mutable_framework_id()->CopyFrom(id); call.set_type(Call::SUPPRESS); mesos.send(call); } AWAIT_READY(suppressOffers); // Wait for suppress to be complete. Clock::pause(); Clock::settle(); // No offers should be sent within 100 mins because the framework // suppressed offers. Clock::advance(Minutes(100)); Clock::settle(); ``` Here is some more info: http://mesos.apache.org/documentation/latest/testing-patterns/ . What do you think ? - Anand Mazumdar On Oct. 23, 2015, 2:32 a.m., Guangya Liu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/39548/ > ----------------------------------------------------------- > > (Updated Oct. 23, 2015, 2:32 a.m.) > > > Review request for mesos and Vinod Kone. > > > Bugs: MESOS-3733 > https://issues.apache.org/jira/browse/MESOS-3733 > > > Repository: mesos > > > Description > ------- > > Root Cause: The reason is that the DECLINE call set filter as 1hr, > the Clock::advance set as 100m. A race condition is that both DECLINE > and SUPPRESS started up in different threads and the call Clock::advance > may be called before SUPPRESS finished. The clock advanced for 100m which > is greater than 1hr, this caused the allocator start to allocate resource > again and ASSERT_TRUE(event.isPending()) will be failed. > > Solution: Call SUPPRESS first, and make sure SUPPRESS call ready before > call DECLINE. > > > Diffs > ----- > > src/tests/scheduler_tests.cpp 7946cb48d62f4ed6d0fdbc771746518e31921f97 > > Diff: https://reviews.apache.org/r/39548/diff/ > > > Testing > ------- > > Platform: Ubuntu 14.04 > make > make check > bin/mesos-tests.sh --gtest_filter="ContentType/SchedulerTest.Suppress/*" > --gtest_repeat=-1 --gtest_break_on_failure > > > Thanks, > > Guangya Liu > >
