On 22 Jul 2014, at 6:02 am, Radim Kubacki <radim.kuba...@gradleware.com> wrote:
> > > > On Mon, Jul 21, 2014 at 1:15 AM, Adam Murdoch <adam.murd...@gradleware.com> > wrote: > > On 10 Jul 2014, at 2:30 am, Radim Kubacki <radim.kuba...@gradleware.com> > wrote: > >> Hi, >> >> here are some comments to >> https://github.com/gradle/gradle/blob/master/design-docs/tooling-api-cancellation.md >> I think Adam will have comments when he gets back. Since he is not there I >> will share it this way. >> >> Story: Daemon waits short period of time for cancelled operation to complete >> >> I think we need to distinguish between 'request to stop the daemon' and >> 'cancel the build' which is not the case in current spec. >> >> - 'request to stop the daemon' is now implemented in >> DaemonStateControl.requestForcefulStop(). This is called from client side >> using DaemonClient.stop() where Stop command is sent to server that >> processes it in its StopHandler. It can break an existing connection for the >> command that can be running at the moment and will cause the daemon server >> to exit. This works well for CLI call 'gradle --stop' and it is good enough >> as the basic implementation of cancellation >> >> - 'cancel the build': we don't want to stop the server if it is possible to >> stop the execution in some soft way (and within reasonable time). If this >> fails we can either ignore the cancel event or stop the daemon as described >> above. > > There are 4 use cases we want to deal with here: > > 1. Tooling API client cancels a build that it started. > 2. User cancels a command-line build by killing the client using ctrl-c > Do you want to handle this in shutdown hook or using some custom signal > handler? BTW: this cancel affects only one daemon process This is already there. The client simply drops the connection, which ends up in a call to requestForcefulStop() in the daemon. There’s no cancelation protocol between the client and daemon. This is good enough for now. requestForcefulStop() would turn into something to request that the current build be cleaned up. > > 3. The daemon loses the connection to the client. > Do you mean when the connection is not correctly closed? Yes. > > 4. User requests that all daemons be stopped. There will probably be an > equivalent in the tooling api at some point. > It is nice to have to add this to tooling API at the moment IMO. Let’s leave that for now. > > At this stage we can’t distinguish between #2 and #3, but it’s certainly > possible. > > The goal for #1 and #2 is to have the daemon clean up the build within some > reasonable period of time. Same for #3. > > The goal for #4 is to have the daemon clean up the build within some > reasonable period of time, and then exit. There should not be any real > difference between stop and cancel, except that stop also exits the process > at the end. > What if I do (ctrl-c ctrl-c)? Should we speed up the exit then? If we do this > then the reasonable amount of time can be a bit longer. I can imagine this on > command line. I am not sure how to model that in toolingApi reasonably > (possibly as cancel build / close projectConnection). The ctrl-c kill the client, which the daemon sees as a disconnection. The client wouldn't hang around for the cancelation to complete (but `gradle —stop` should). We could potentially wait a short time when the client disappears (#2 and #3) and a longer time when we can give feedback to the client (#1 and #4). -- Adam Murdoch Gradle Co-founder http://www.gradle.org CTO Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
