----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10172/#review19267 -----------------------------------------------------------
src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/10172/#comment39880> thank you src/master/http.cpp <https://reviews.apache.org/r/10172/#comment39882> did you forget to kill this? src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/10172/#comment39893> Great comment! src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/10172/#comment39894> s/Process/process/ ? src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/10172/#comment39895> Pull this down after driver.start() but before driver.launchTasks() src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/10172/#comment39896> The lost status happens much later in the test. Pull this down to where it is expected. src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/10172/#comment39897> s/received/handled/ src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/10172/#comment39898> You could use Future<Protobuf> and DROP_PROTOBUF(). We typically use 'Message', when we are interested in the pids (message.from and message.to). src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/10172/#comment39899> You could simplify this by while(lostStatus.isPending()). But I will leave it up to you. src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/10172/#comment39900> again, you could use FUTURE_PROTOBUF here src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/10172/#comment39901> Excellent test! - Vinod Kone On April 16, 2013, 12:58 a.m., Ben Mahler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/10172/ > ----------------------------------------------------------- > > (Updated April 16, 2013, 12:58 a.m.) > > > Review request for mesos, Benjamin Hindman and Vinod Kone. > > > Description > ------- > > See above. This is a fix of MESOS-305. > > This also fixes MESOS-362. > > > This addresses bugs MESOS-305 and MESOS-362. > https://issues.apache.org/jira/browse/MESOS-305 > https://issues.apache.org/jira/browse/MESOS-362 > > > Diffs > ----- > > src/detector/detector.cpp 7a8355162d543e017505dd58efd2d7bf96f99623 > src/master/http.cpp 71b04f01f45ee73d9c246f469e1368223903abed > src/master/master.hpp 9776a7cb8448e41e5d52288e3c637737cee15a08 > src/master/master.cpp 5b0e8c03c516f9fc8bb729c21e876bdde89baf9c > src/tests/fault_tolerance_tests.cpp > bfb30344ca02cd42c442a373d44d6a3fa287c1e3 > src/tests/master_detector_tests.cpp > 980f3c720301b83af668e10f479adb9cce4f0c9f > > Diff: https://reviews.apache.org/r/10172/diff/ > > > Testing > ------- > > make check > > Added tests for the partitioned slave re-registration. > ./bin/mesos-tests.sh > --gtest_filter="FaultToleranceTest.PartitionedSlaveReregistration" --verbose > --gtest_break_on_failure --gtest_repeat=3000 > > Ran into MESOS-406, but otherwise no issues. > > Will be adding ZK master detector tests shortly to test that the > NoMasterDetectedMessages are being sent. > > > Thanks, > > Ben Mahler > >
