Quantcast

Re: cancellation

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cancellation

Adam Murdoch

On 10 Jul 2014, at 2:30 am, Radim Kubacki <[hidden email]> 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
3. The daemon loses the connection to the client.
4. User requests that all daemons be stopped. There will probably be an equivalent in the tooling api at some point.

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.

Implementation-wise, the first cut of “clean up the build” is simply to exit the process.

The second step (the story in question) would be to change the implementation to:
1. wait for a short period of time for the current operation to complete
2. if the operation does not complete in this time, request that the process exit.

stop becomes:
1. attempt cancelation and wait until there is a result.
2. request that the process exit.

The third step would be to get some of the workers involved in cancelation, starting with the task execution graph. When cancelation is requested, the task graph will no longer start executing tasks, but will continue to execute whatever it is currently executing.

Later steps can do similar things for configuration actions and tooling builders.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cancellation

Radim Kubacki



On Mon, Jul 21, 2014 at 1:15 AM, Adam Murdoch <[hidden email]> wrote:

On 10 Jul 2014, at 2:30 am, Radim Kubacki <[hidden email]> 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 
 
3. The daemon loses the connection to the client.
Do you mean when the connection is not correctly closed? 
 
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. 

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).
 

Implementation-wise, the first cut of “clean up the build” is simply to exit the process.

The second step (the story in question) would be to change the implementation to:
1. wait for a short period of time for the current operation to complete
2. if the operation does not complete in this time, request that the process exit.
Yes, so it is really a bit different from stop where the daemon exits. 

stop becomes:
1. attempt cancelation and wait until there is a result.
2. request that the process exit.
Sounds reasonable. It's not there yet but I think I can do it soon.
 

The third step would be to get some of the workers involved in cancelation, starting with the task execution graph. When cancellation is requested, the task graph will no longer start executing tasks, but will continue to execute whatever it is currently executing.
I will have questions about this too later. :-) 

Later steps can do similar things for configuration actions and tooling builders.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cancellation

Adam Murdoch

On 22 Jul 2014, at 6:02 am, Radim Kubacki <[hidden email]> wrote:




On Mon, Jul 21, 2014 at 1:15 AM, Adam Murdoch <[hidden email]> wrote:

On 10 Jul 2014, at 2:30 am, Radim Kubacki <[hidden email]> 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



Loading...