----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16232/#review30317 -----------------------------------------------------------
src/main/java/com/twitter/aurora/scheduler/async/AsyncModule.java <https://reviews.apache.org/r/16232/#comment58034> The help string could use some more detail, thinking out loud: "Time to reserve a slave's offers while trying to satisfy a task preempting another." src/main/java/com/twitter/aurora/scheduler/async/AsyncModule.java <https://reviews.apache.org/r/16232/#comment58035> I'm 99% this works fine because you've exposed the key you're binding against (i suspect that's _why_ you exposed it), but can you confirm that a test fails if this is not wired properly? src/main/java/com/twitter/aurora/scheduler/async/TaskGroups.java <https://reviews.apache.org/r/16232/#comment58036> Realizing this may have been dropped in the internal review: Thinking even further on this, perhaps the tryPreempt() behavior should be implicit to schedule(), and the schedule() outcome becomes an enum SUCCESS, TRY_LATER? src/main/java/com/twitter/aurora/scheduler/async/TaskScheduler.java <https://reviews.apache.org/r/16232/#comment58037> Better doc? src/main/java/com/twitter/aurora/scheduler/async/TaskScheduler.java <https://reviews.apache.org/r/16232/#comment58038> please leave an empty line between wrapped method signature and body src/main/java/com/twitter/aurora/scheduler/async/TaskScheduler.java <https://reviews.apache.org/r/16232/#comment58039> How about getSlaveReservation()? "is" implies boolean to me, while "get" suggests a response (which might be empty) src/main/java/com/twitter/aurora/scheduler/async/TaskScheduler.java <https://reviews.apache.org/r/16232/#comment58043> Some tiny comments would improve readability of this tri-state behavior: if (reservedTaskId.isPresent()) { if (taskId.equals(reservedTaskId.get()) { // Slave is reserved to satisfy this task. return assigner.maybeAssign(offer, task); } else { // Slave is reserved for another task. return Optional.absent(); } } else { // Slave is not reserved. return assigner.maybeAssign(offer, task); } src/main/java/com/twitter/aurora/scheduler/async/TaskScheduler.java <https://reviews.apache.org/r/16232/#comment58045> There's a bit of a feature gap here — if the task _is_ assigned, the reservation should be cleared so we can promptly schedule others. It may be tempting to call the O(n) invalidateTask(), but i suggest adding the O(1) invalidateSlave(). Please write a failing test for this behavior, then fix. src/main/java/com/twitter/aurora/scheduler/async/TaskScheduler.java <https://reviews.apache.org/r/16232/#comment58049> This routine can be simplified, since Cache's contract states that asMap() returns a view, and modifications are possible through the view. So, you can do this: reservations.asMap().values().remove(taskId); src/test/java/com/twitter/aurora/scheduler/async/TaskSchedulerImplTest.java <https://reviews.apache.org/r/16232/#comment58051> I should have given better guidance in the last round. What i meant was just let them propagate unchanged, by removing try/catch, and changing the test method signature to "throws Exception". src/test/java/com/twitter/aurora/scheduler/async/TaskSchedulerImplTest.java <https://reviews.apache.org/r/16232/#comment58052> please remove all of these src/test/java/com/twitter/aurora/scheduler/async/TaskSchedulerImplTest.java <https://reviews.apache.org/r/16232/#comment58053> extra newline - Bill Farner On Dec. 13, 2013, 1:11 a.m., Zameer Manji wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/16232/ > ----------------------------------------------------------- > > (Updated Dec. 13, 2013, 1:11 a.m.) > > > Review request for Aurora, Kevin Sweeney, Maxim Khutornenko, and Bill Farner. > > > Bugs: AURORA-11 > https://issues.apache.org/jira/browse/AURORA-11 > > > Repository: aurora > > > Description > ------- > > This patch adds a reservation system the preemption flow. > > The reservation associates a slave id with a task id for a fixed duration. If > the task attempts to schedule itself during that time period and an offer is > available from that slave then it will be scheduled. If another task attempts > to schedule itself then it will not use the reserved offer. > > > Diffs > ----- > > src/main/java/com/twitter/aurora/scheduler/async/AsyncModule.java > db07841543e554e269f6fe7b36d7f7232af21140 > src/main/java/com/twitter/aurora/scheduler/async/Preemptor.java > e5aeb8321e22c51eb3a5dad3d3dd1e26b7121b7d > src/main/java/com/twitter/aurora/scheduler/async/TaskGroups.java > f95f719c5a444b0f8faa4330852e251dd5de528e > src/main/java/com/twitter/aurora/scheduler/async/TaskScheduler.java > fbd82ff70235294cfd27c242f141a585d6bb2396 > src/test/java/com/twitter/aurora/scheduler/async/TaskSchedulerImplTest.java > PRE-CREATION > src/test/java/com/twitter/aurora/scheduler/async/TaskSchedulerTest.java > a747f2b1ecbad7263931aeec3b12711096d2469d > > Diff: https://reviews.apache.org/r/16232/diff/ > > > Testing > ------- > > ./gradlew clean build > > > Thanks, > > Zameer Manji > >
