----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/40935/#review108911 -----------------------------------------------------------
Ship it! Tested on Centos7. There still appears to be some flakiness (in the first inverse offer filter) that requires further investigation. But these changes make the test significantly more stable. I vote for committing this patch, but keeping the JIRA open until we nail down the flakiness for good. src/tests/master_maintenance_tests.cpp (lines 1485 - 1488) <https://reviews.apache.org/r/40935/#comment168372> It might be valuable to expect an update for each task. Maybe check: `updateStatus.task_id() == taskInfo1.task_id() || updateStatus.task_id() == taskInfo2.task_id()` And between the two acknowledges, you could do: `updateStatus.task_id() != event.get().update().status().taskid()` ---- Note: As far as I know, no other HTTP scheduler library test launches two tasks simultaneously. - Joseph Wu On Dec. 3, 2015, 4:17 p.m., Neil Conway wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/40935/ > ----------------------------------------------------------- > > (Updated Dec. 3, 2015, 4:17 p.m.) > > > Review request for mesos, Joris Van Remoortere and Joseph Wu. > > > Bugs: MESOS-4059 > https://issues.apache.org/jira/browse/MESOS-4059 > > > Repository: mesos > > > Description > ------- > > There were two problems: > > (1) After launching two tasks, we assumed that we would see TASK_RUNNING > updates > for the tasks in the same order they were launched. This is not > guaranteed, > so adjust the test to handle TASK_RUNNING updates in the order they are > received. > > (2) The test used this pattern: > > Mesos m; > Call c; > > m.send(c); > Clock::settle(); > // Trigger a new batch allocation that reflects the call > Clock::advance(); > > However, this is actually unsafe (see MESOS-3760): the send() call might > not > have reached the master by the time `Clock::settle()` happens. This was > fixed by blocking using `FUTURE_DISPATCH` on the downstream logic in the > allocator that is invoked to handle the delivered event. > > > Diffs > ----- > > src/tests/master_maintenance_tests.cpp > 00900561a1b8dd03a7a2f3d60a036b4beb920aa1 > > Diff: https://reviews.apache.org/r/40935/diff/ > > > Testing > ------- > > ./src/mesos-tests --gtest_filter="MasterMaintenanceTest.InverseOffersFilters" > --gtest_repeat=2000 # on OSX > ./src/mesos-tests --gtest_filter="MasterMaintenanceTest.InverseOffersFilters" > --gtest_repeat=100 # on Ubuntu Wily (slow VM) > > > Thanks, > > Neil Conway > >
