[GRADLE-1073] Gradle daemon should gracefully handle version changes Created: 28/Jul/10 Updated: 04/Jan/13 Resolved: 24/Nov/10
|Reporter:||Chris Beams||Assignee:||Adam Murdoch|
It appears that the gradle process does a blind check for a running daemon and if it's up, attempts to communicate with it. Better would be issuing a version check first, shutting down and restarting the daemon if versions are incompatible.
A minor issue perhaps, but goal number one with the daemon is to make it invisible.
Another use case for this would be not an upgrade of gradle, but simply moving between different gradle-built projects that are using different versions in the wrapper. In this case, it might be best to start a second daemon on its own dedicated port. It's a bit of an edge case, but if a user is toggling between two projects and issuing builds, they'll continually incur the daemon startup overhead. Shouldn't be a problem to just spin up a new daemon, but this does create the possibility of stale daemons lying around after a legitimate upgrade occurs.
|Comment by Chris Beams [ 09/Sep/10 ]|
Another stack trace just gotten when upgrading to 0.9-build-daemon-20100909161815+1000:
This would persist with all subsequent ./gradlew -t invocations, but was solved by kill -9 <GRADLE_DAEMON_PID> and retrying ./gradlew -t
|Comment by Chris Beams [ 27/Oct/10 ]|
As an update, I just upgraded from the gradle_daemon branch from Oct 25th. I had the daemon running in the background on that version, then upgraded to 0.9-build-daemon-20101027111821+1100. Upon trying to run a gradle command after upgrading, gradle simply exited silently – no stack trace, and nothing even when passing in -d.
Upon running ./gradlew --stop, the old daemon shut down as expected and the new version started up on the next invocation.
At any rate, that experience would have been pretty tough to deal with for someone unfamiliar with the details of the daemon. And while it's not likely a normal build operator would be doing such an upgrade on a regular basis, it may be relatively frequent for our developers as we keep up to date with daemon updates and fixes over the next few weeks.