----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16724/#review34767 -----------------------------------------------------------
src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/16724/#comment65021> kill newline. src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/16724/#comment65023> const string& src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/16724/#comment65024> s/+/ + / src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/16724/#comment65025> new line. src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/16724/#comment65067> Kill this. src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/16724/#comment65059> Why do you need to AWAIT on this? src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/16724/#comment65068> Kill this. src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/16724/#comment65060> Why AWAIT on this? src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/16724/#comment65063> s/Framework/framework/ src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/16724/#comment65064> s/execShutdown/shutdown/ src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/16724/#comment65076> Do you need to wait on both? If no, kill one of them. src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/16724/#comment65077> ditto. src/tests/fault_tolerance_tests.cpp <https://reviews.apache.org/r/16724/#comment65078> s/Framework/framework/ src/tests/mesos.hpp <https://reviews.apache.org/r/16724/#comment65065> Why not augment createTask() above? Also, it seems a bit weird to use DEFAULT_EXECUTOR_INFO as Task.ExecutorInfo. - Vinod Kone On Feb. 18, 2014, 12:23 a.m., Adam B wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/16724/ > ----------------------------------------------------------- > > (Updated Feb. 18, 2014, 12:23 a.m.) > > > Review request for mesos, Benjamin Hindman, Ben Mahler, Niklas Nielsen, and > Vinod Kone. > > > Bugs: MESOS-767 > https://issues.apache.org/jira/browse/MESOS-767 > > > Repository: mesos-git > > > Description > ------- > > Added completed frameworks/tasks to slave re-registration. > Fixes MESOS-767. > > Additional issues discovered during investigation: > - MESOS-905: Remove Framework.id in favor of FrameworkInfo.id > - MESOS-906: Last task in Completed Framework never graduates from > terminatedTasks to completedTasks. > - Completed frameworks/executors/tasks are stored in circular buffers, > and these may overflow in different orders on different slaves. > BenH proposes an archive to replace these circular buffers. > > > Diffs > ----- > > include/mesos/scheduler.hpp 2e4707e > src/master/master.hpp 7649737 > src/master/master.cpp 77872ec > src/messages/messages.proto 922a8c4 > src/slave/slave.cpp 2d21e16 > src/tests/fault_tolerance_tests.cpp 60e06cc > src/tests/mesos.hpp d7bdaee > > Diff: https://reviews.apache.org/r/16724/diff/ > > > Testing > ------- > > make check; manually failed-over a master, watched the slave reregister its > completed frameworks, web UI shows completed tasks and stdout/stderr. > Added a new unit/integration test to verify the expected behavior. > > > Thanks, > > Adam B > >
