-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23912/
-----------------------------------------------------------
(Updated Sept. 17, 2014, 6:47 p.m.)
Review request for mesos.
Changes
-------
Addressed all issues. Adapted to changes from rebasing changes related to the
hashmap for pending tasks. Thus no longer depending on the proposed small
change to stout - cancelling that.
Bugs: MESOS-947
https://issues.apache.org/jira/browse/MESOS-947
Repository: mesos-git
Description (updated)
-------
Fixes MESOS-947 "Slave should properly handle a killTask() that arrives between
runTask() and _runTask()".
Slave::killTask() did not check for task in question combination to be
"pending" (i.e. Slave::runTask had happened, but Slave::_runTask had not yet)
and then erroneously assumed that Slave::runTask() had not been executed. The
task was then marked "LOST" instead of "KILLED". But Slave::runTask had already
scheduled Slave::_runTask to follow. Now the entry for being "pending" is
removed, and the task is marked "KILLED", and _runTask gets informed about
this. It checks whether the task in question is currently "pending" and if it
is not, then it infers that the task has been killed and does not erroneously
try to complete launching it.
Diffs (updated)
-----
src/slave/slave.hpp 4f3df5c49a8cf72fc7153158c9eb045196b6cf13
src/slave/slave.cpp 28eb02852ddcc10efe589a8069dba9c895bc160e
src/tests/mesos.hpp 957e2233cc11c438fd80d3b6d1907a1223093104
src/tests/mesos.cpp 3dcb2acd5ad4ab5e3a7b4fe524ee077558112773
src/tests/slave_tests.cpp 69be28f6e82b99e23424bd2be8294f715d8040d4
Diff: https://reviews.apache.org/r/23912/diff/
Testing (updated)
-------
Wrote a unit test that reliably created the situation described in the ticket.
Observed that TASK_LOST and the listed log output occurred. This pointed
directly to the lines in killTask() where the problem is rooted. Ran the test
after fixing, it succeeded. Checked the log. It looks like a "clean kill" now
:-)
Thanks,
Bernd Mathiske
