----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/54889/#review159727 -----------------------------------------------------------
Can we add an expectation for exactly when we expect to receive the offer? i.e., another `WillOnce(FutureSatisfy(...))` and then wait for the future at the appropriate time. The thing I don't like about the `WillRepeatedly(...)` pattern is that it obscures whether additional offers are actually expected or not. Lots of tests have copied this pattern and use it, even when another offer is not actually expected. - Neil Conway On Dec. 20, 2016, 11:54 a.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/54889/ > ----------------------------------------------------------- > > (Updated Dec. 20, 2016, 11:54 a.m.) > > > Review request for mesos, Alexander Rukletsov and Neil Conway. > > > Bugs: MESOS-6820 > https://issues.apache.org/jira/browse/MESOS-6820 > > > Repository: mesos > > > Description > ------- > > The test FaultToleranceTest.FrameworkReregister observes a single > offer in order to monitor progress and as a trigger to initiate other > orders later in the test. The change installs expectations for > possibly additional offers. This allows for the thread running the > test body to be delayed with respect to the master thread which could > in the meantime hand out additional offers. > > > Diffs > ----- > > src/tests/fault_tolerance_tests.cpp > 05937a917a2c175aa53b52488febb7cfd8400a13 > > Diff: https://reviews.apache.org/r/54889/diff/ > > > Testing > ------- > > `make check` (OS X, clang-trunk, w/ optimizations, SSL) > > Before this fix `FaultToleranceTest.FrameworkReregister` failed for me > multiple times in ~10k iterations; after this patch it didn't fail in a > single run I stopped after 170k iterations. > > > Thanks, > > Benjamin Bannier > >
