> On Nov. 23, 2015, 6:45 p.m., Neil Conway wrote: > > An alternative would be to pause and advance the clock by the > > allocation_interval. Do you think that would be worth doing instead? > > Alexander Rukletsov wrote: > That's correct. I was not sure what approach is easier to understand. > After you input I have checked the "testing-patterns.md" doc and it looks > like clock magic is well documented and may therefore be a preferred > solution. Will update the patch shortly.
Please check the updated version, slightly more intrusive. - Alexander ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/39320/#review107625 ----------------------------------------------------------- On Nov. 24, 2015, 1:13 p.m., Alexander Rukletsov wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/39320/ > ----------------------------------------------------------- > > (Updated Nov. 24, 2015, 1:13 p.m.) > > > Review request for mesos, Benjamin Bannier, Bernd Mathiske, Neil Conway, and > Till Toenshoff. > > > Bugs: MESOS-3732 > https://issues.apache.org/jira/browse/MESOS-3732 > > > Repository: mesos > > > Description > ------- > > See summary. > > > Diffs > ----- > > src/tests/fault_tolerance_tests.cpp > 3bbd6cbf6b101415c90991c48f00f33a5aff5590 > src/tests/mesos.hpp a2a76f55f9a4091cccfccd9672c2d2897b34ddcd > src/tests/mesos.cpp b2211d59ed571ec8ddc132f69ed1cf5da9eeef10 > > Diff: https://reviews.apache.org/r/39320/diff/ > > > Testing > ------- > > make check > > The run time for the `FaultToleranceTest.FrameworkReregister` test has > reduced from more than `1s` to less than `100ms`. > Before: > ``` > [ RUN ] FaultToleranceTest.FrameworkReregister > [ OK ] FaultToleranceTest.FrameworkReregister (1018 ms) > ``` > After: > ``` > [ RUN ] FaultToleranceTest.FrameworkReregister > [ OK ] FaultToleranceTest.FrameworkReregister (49 ms) > ``` > > > Thanks, > > Alexander Rukletsov > >
