Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support Build Cancellation in `JavaExec` Task #1128
Edit: Improved description to reference the more generic solution (build cancel event) as oppose to the specific usage of this feature (Ctrl-D) explained by Gary's comment.
Initial discussion in #1109
Steps to Reproduce (for bugs)
referenced this issue
Jan 9, 2017
One more comment: the 10s delay is not acceptable in many scenarios. For example when developing a server application you will frequently restart you application. You will require a fast restart and a clean restart, that leaves a coherent state.
Idea 2016.3 has an option to delegate run task to Gradle. Then, when you run the application, Idea executes 'run' for you, although you may not know what exactly is happening under the hood. When not using delegating, using the 'restart' button for a server app in Idea is smooth and fast. With delegating to Gradle, it often failed for me because of port still being used. Probably this is because Gradle daemon waits 10s but Idea starts a new build immediately. Also restarting feels not right, because you don't see console logs about server being stopped - again, because of the 10s delay of running shutdown hooks.
The 10s delay is a byproduct of the fact that the task never finishes. What happens when you send a ctrl-c is that it terminates the daemon client. The client disappearing then causes the daemon to cancel any running builds associated with that client. The build cancellation logic (as it currently exists) checks in between tasks to see if the build has been canceled, so it relies on the currently running task(s) to complete before it can stop the build. In this case, the
So, another way to handle this is to provide better mechanics for tasks to respond to cancellation. For instance, allow tasks to register a cancellation hook so that when a cancellation occurs, we can notify a running task that we are waiting for it to finish and it could stop early rather than running to completion. In the case of the
For a more controlled shutdown (i.e. allowing any stdout/stderr to make it back to the client) we might generalize ctrl-d to more formally mean "cancel the build" in which case it would send a cancellation request to the daemon which would work exactly the same as the ctrl-c case except that the client would remain connected until the cancellation was complete (and any output would be piped back to the console).
I think we wouldn't make
Yet another problem manifesting in Idea 2016.3 and 2017.1. If you create a Run Configuration for 'gradle run', run it, then try to close the current project or the whole Idea, you will be asked if you want to Terminate, Disconnect or Cancel. 'Terminate' will hang forever.
I reported this as https://youtrack.jetbrains.com/issue/IDEA-170956
referenced this issue
Jun 6, 2017
I have similar issues where I have a JavaExec-based "run" task for testing. I'm working on an application that runs continuously in the background and it doesn't stop by itself. This means I have to ctrl-c the process which kills the Gradle daemon as discussed earlier. The shutdownhooks are not called in my app either. I have similar issues using IntelliJ when I re-run my project from the IDE with a Gradle run/build configuration that only allows one instance to be running at the same time.
Except for the annoying time delay caused by starting a new Gradle daemon every time I am also running into issues because my app cannot shut down gracefully (e.g. the WebSocket server not shutting down gracefully which keeps ports blocked for another 10-20 seconds after the ctrl-c). All of this together makes it very tedious to use Gradle for this scenario. I just want to kill my app, let it shut down gracefully and start it again which really shouldn't take more than a few seconds.
I would really like to have a method for telling the daemon to stop the running JavaExec task and to let it shut down gracefully. Preferably in a way that integrates well with the IDE. I don't consider manually executing a command to find my app pid and kill it a clean solution.
This is also a problem for anyone who is using