----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10604/#review19417 -----------------------------------------------------------
src/slave/slave.cpp <https://reviews.apache.org/r/10604/#comment40156> Well, if the slave re-registers we won't send TASK_LOST in the master, we'll be sending killTask to the slave. But only once I implement the task consolidation in the master during re-registration. src/slave/slave.cpp <https://reviews.apache.org/r/10604/#comment40157> great! src/slave/slave.cpp <https://reviews.apache.org/r/10604/#comment40163> Can you move this TODO to be for the statusUpdate() call? src/slave/slave.cpp <https://reviews.apache.org/r/10604/#comment40158> s/guaranteed/guarantee/ src/slave/slave.cpp <https://reviews.apache.org/r/10604/#comment40159> s/would cause/causes/ src/slave/slave.cpp <https://reviews.apache.org/r/10604/#comment40160> RECOVERING src/slave/slave.cpp <https://reviews.apache.org/r/10604/#comment40165> s/master/the master/ src/slave/slave.cpp <https://reviews.apache.org/r/10604/#comment40161> Unless it recovers and re-registers, in which case the master will send killTask to this slave. s/send send/send/ src/slave/slave.cpp <https://reviews.apache.org/r/10604/#comment40162> Same line as the CHECK? src/slave/slave.cpp <https://reviews.apache.org/r/10604/#comment40166> Add a note as to why we don't send an update? Because we don't want to send conflicting status updates for this task, correct? src/slave/slave.cpp <https://reviews.apache.org/r/10604/#comment40167> Bad sentence: "will be removed all those tasks" src/slave/slave.cpp <https://reviews.apache.org/r/10604/#comment40172> Curious if this is related, or you just noticed this bug as well so fixing it here? src/slave/slave.cpp <https://reviews.apache.org/r/10604/#comment40170> great! - Ben Mahler On April 18, 2013, 11:46 p.m., Vinod Kone wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/10604/ > ----------------------------------------------------------- > > (Updated April 18, 2013, 11:46 p.m.) > > > Review request for mesos, Benjamin Hindman and Ben Mahler. > > > Description > ------- > > Refactored runTask() and some other pieces of slave, to make this hopefully > clear. > > Also, sneaked in some bug fixes when executorStarted() is called. > > > Diffs > ----- > > src/slave/slave.hpp 54c66863db217077a050dc414caf0976447500be > src/slave/slave.cpp 00b2375505e362959ac34061e3066cf8ace96adf > src/tests/allocator_zookeeper_tests.cpp > 42faaa067bdfa0c7f33260eb5cb3b9e5956c3037 > > Diff: https://reviews.apache.org/r/10604/diff/ > > > Testing > ------- > > make check. > > NOTE: GarbageCollectorIntegrationTest.Unschedule test now correctly verifies > that executors/frameworks are properly unscheduled despite adding tasks to > 'pending'. > > > Thanks, > > Vinod Kone > >
