Gradle daemon becomes unusable

After using the gradle daemon a lot, eventually it becomes unusable. By this I mean, that when I try to use it, it will wait a long time and eventually reports an error that it have tried to connect 100 different Gradle daemon without success. Usually there are no java processes are running (though sometimes there are java process executing the Gradle daemon) and deleting the “daemon” directory in the “.gradle” directory solves the problem.

This problem is rather frustrating because the Tooling api requires me to use the Gradle daemon. That is, I see no way to avoid using it.

I believe I currently use the binaries for the Tooling api found in Gradle 1.0. It seems, that it does not matter what version (1.0 or 1.1) I specify using the ‘GradleConnector.useInstallation’ method.

Please provide the exact error message and stack trace. Which OS? How are you leveraging the daemon/tooling API?

Currently I cannot give you a stacktrace because regretably I did not save it. Next time it occurs, I will. Note however, that this problem does not occur very frequently but once it does, the problem will persist until the daemon folder is deleted (not even system restart helps).

I have seen this issue on Windows systems (7, Vista, Xp) and not tried with others.

I use the tooling API to provide a plugin for NetBeans: All code relevant to this issue can be found here:

Luckily, I found the stack trace in the log of NetBeans:

org.gradle.launcher.daemon.client.NoUsableDaemonFoundException: Unable to find a usable idle daemon. I have connected to 100 different daemons but I could not use any of them to run build: Build{id=ee7502e0-aaa5-4be1-b0bd-e86870f7d8ac.1, currentDir=C:\Program Files\NetBeans 7.2}.

at org.gradle.launcher.daemon.client.DaemonClient.execute(

at org.gradle.launcher.daemon.client.DaemonClient.execute(

at org.gradle.tooling.internal.provider.DaemonGradleLauncherActionExecuter.execute(

at org.gradle.tooling.internal.provider.DaemonGradleLauncherActionExecuter.execute(

at org.gradle.tooling.internal.provider.LoggingBridgingGradleLauncherActionExecuter.execute(

at org.gradle.tooling.internal.provider.LoggingBridgingGradleLauncherActionExecuter.execute(


at org.gradle.tooling.internal.provider.DefaultConnection.getTheModel(

at org.gradle.tooling.internal.consumer.connection.AdaptedConnection.getModel(

at org.gradle.tooling.internal.consumer.ModelProvider.provide(

at org.gradle.tooling.internal.consumer.connection.LazyConnection$

at org.gradle.tooling.internal.consumer.connection.LazyConnection.withConnection(

at org.gradle.tooling.internal.consumer.connection.LazyConnection.getModel(

at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConnection$


at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConnection.getModel(

at org.gradle.tooling.internal.consumer.connection.LoggingInitializerConnection.getModel(

at org.gradle.tooling.internal.consumer.async.DefaultAsyncConnection$

at org.gradle.tooling.internal.consumer.async.DefaultAsyncConnection$

Caused: org.gradle.tooling.GradleConnectionException: Could not fetch model of type ‘IdeaProject’ using Gradle installation ‘C:\Program Files\Gradle\gradle-1.1’.

at org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(

at org.gradle.tooling.internal.consumer.async.DefaultAsyncConnection$

at org.gradle.messaging.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$

at java.util.concurrent.ThreadPoolExecutor.runWorker(

at java.util.concurrent.ThreadPoolExecutor$

[catch] at

Attila, do you think it would be possible to reproduce the issue in reasonable time? Can you provide the steps?

When the problem occurs next time, before deleting the daemon folder can you zip it up and attach it to the jira ticket (I’ll create the ticket). The daemon folder should contain logs from the daemons.

Exported to jira: GRADLE-2444

Actually I think, I have just found a way to reproduce this issue:

  1. Load a project with the NetBeans plugin mentioned above. (possibly, build it). 2. Verify that the process running the Gradle daemon is still in the memory. 3. Restart the OS. 4. Next time, attempting to load anything with the gradle daemon, will trigger the problem. (even if it is done via the command line).

I will try this one out again to be sure and will send the zipped daemon folder.

Yes, it seems to be a good way to reproduce it (although I’m sure that it is not the only way possible).

I have attached the daemon folder to the jira ticket.

Attila, if you can reproduce the problem from the command line would you be so kind and attach a log from the command line execution? With -debug and -s please.

Thanks a bunch!