I'm guessing most of the motivation here is actually for task killing escalation in the command executor? The shutdown grace period was designed for executor shutdown only, which today occurs only when the framework is being shutdown (or recovery is cleaning up), or in the future, when frameworks ask to shutdown a specific executor.
In the case of the command executor, the slave won't do any escalation when a killTask arrives, since it's not trying to shutdown the executor. For simplicity (I'm guessing), we conflated the executor shutdown grace period, with the killTask signal escalation in the command executor. So, I'm still trying to figure out the concrete use case here, is it that you have command-tasks that implement a clean shutdown driven by SIGTERM? Going forward, is that enough or would we want a more general notion of "Finalization" (e.g. driven by HTTP, or SIGTERM, or subprocess, etc), much like the generic health checking that was added. On Mon, Nov 10, 2014 at 8:08 AM, Alex Rukletsov <[email protected]> wrote: > Hi all, > > I would like to share the design doc for configurable grace period > < > https://docs.google.com/document/d/1_b3OPv3tjkub1T6VhQ27GnDfbVjnJ6IQ4ufPQhV1HM8/edit?usp=sharing > >. > The doc describes two approaches to calculate nested grace periods, points > out implementation details and opens several design questions. > > I would highly appreciate any thoughts, ideas and suggestions! > > Thanks, > Alex >
