> On March 20, 2015, 3:52 p.m., Joe Smith wrote:
> >
>
> Joe Smith wrote:
> It seems like the `self.quitquitquit` is the important part (on line 340
> of the runner)- doesn't decreasing the timeout not give `quitquitquit` the
> time it needs?
>
> Joe Smith wrote:
> In `src/main/python/apache/aurora/executor/thermos_task_runner.py`
>
> ```
> 331 waited = Amount(0, Time.SECONDS)
>
> 332 while self.is_alive and waited < timeout:
>
> 333 self._clock.sleep(self.POLL_INTERVAL.as_(Time.SECONDS))
>
> 334 waited += self.POLL_INTERVAL
>
> 335
>
> 336 if not self.is_alive and self.task_state() != TaskState.ACTIVE:
>
> 337 return
>
> 338
>
> 339 log.info('Thermos task did not shut down cleanly, rebinding to
> kill.')
> 340 self.quitquitquit()
>
> 341
>
> 342 while not self._monitor.finished and waited < timeout:
>
> 343 self._clock.sleep(self.POLL_INTERVAL.as_(Time.SECONDS))
>
> 344 waited += self.POLL_INTERVAL
> ```
>
> Is it that we need to reset waited to Amount(0, Time.SECONDS) ?
friendly ping
- Joe
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/32221/#review77296
-----------------------------------------------------------
On March 18, 2015, 6:20 p.m., Brian Wickman wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32221/
> -----------------------------------------------------------
>
> (Updated March 18, 2015, 6:20 p.m.)
>
>
> Review request for Aurora and Bill Farner.
>
>
> Bugs: AURORA-1054
> https://issues.apache.org/jira/browse/AURORA-1054
>
>
> Repository: aurora
>
>
> Description
> -------
>
> Remove excessively low timeout in SIGTERM swallowing test.
>
>
> Diffs
> -----
>
> src/test/python/apache/aurora/executor/test_thermos_task_runner.py
> 6b24bbb2ab7ca16f97961aabeed945b61e5b5908
>
> Diff: https://reviews.apache.org/r/32221/diff/
>
>
> Testing
> -------
>
> Cannot reproduce locally, but 5 seconds is an impossibly small timeout, even
> if we aren't testing SIGTERM swallowing. If this fails, we will get tripped
> by 60s timeout instead.
>
>
> Thanks,
>
> Brian Wickman
>
>
