> On April 26, 2017, 1:20 a.m., David McLaughlin wrote: > > How is the affect of changes like this measured? Seems very hunch-driven, > > whereas other potential performance reviews were met with requests for > > methodology, etc.
Also, generally good to have at least two Ship Its per review? Let's make sure we follow that convention. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58611/#review173008 ----------------------------------------------------------- On April 21, 2017, 10:36 a.m., Stephan Erb wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/58611/ > ----------------------------------------------------------- > > (Updated April 21, 2017, 10:36 a.m.) > > > Review request for Aurora and Zameer Manji. > > > Repository: aurora > > > Description > ------- > > It is not very common that kills are dropped by Mesos and have to be retried > by Aurora. It therefore makes sense to slightly increase the retry timeout > so that we don't retry needlessly when Thermos is still busy executing > the lifecycle methods. > > By default, Thermos uses the following kill escalation sequence: > > * /quitquitquit > * wait 5s > * /abortabortabort > * wait 5s > * SIGTERM > * wait up to 1 minute > * SIGKILL > > > Diffs > ----- > > > src/main/java/org/apache/aurora/scheduler/reconciliation/ReconciliationModule.java > e076e802f8920b37cef202520c7fbe59724dd06d > > > Diff: https://reviews.apache.org/r/58611/diff/1/ > > > Testing > ------- > > ./gradlew -Pq build > > > Thanks, > > Stephan Erb > >
