Build slow, needs more daemons

Help/Discuss
1

I frequently test my client-server game by running :server:run and :client:run at the same time (as separate commands). One of the tasks tends to be far slower than the other. Using --status, I noticed that, within seconds of stopping the ‘run’ tasks, all idle daemons except one die off. This forces one of the daemons to be restarted almost every time I test-run the game, adding a whopping 6 seconds to the 2 second build time and completely defeating the purpose of a daemon - fast builds.

How do I make gradle keep two or three idle daemons alive? (I may need a third for continuous build.)

Or at least, how else can I reduce the time between making code changes and running the game?

EDIT: Running “:server:run :client:run” in the same command with parallel builds enabled almost does what I want. But then I can’t re-run the server/client independently of each other.

EDIT: Found an ugly fix! If I make the daemons incompatible with each other by changing one of these options, they will all stay alive. So I gave each of my run configurations in IntelliJ a different VM option, e.g. -Xms255m, -Xms254m, -Xms253m, etc, and now my builds are fast! :smiley:

EDIT: Also created an idea.properties file containing this setting to increase idle timeout from 1 minute to 3 hours:
external.system.remote.process.idle.ttl.ms=10800000

2

@eriwen Is this our duplicate daemon expiration at work? Is there a way to configure it?

The JetBrains team is aware of the problem and they will remove the short timeout in the next version.

3

This is likely the duplicate idle daemon expiration kicking in. There isn’t currently a way to configure it, but you can work around it by making them not duplicates. For instance, you could give one an extra byte of maximum heap, or set a system property on one that isn’t set on the other. When you do so, gradle will not consider them duplicates and the normal daemon idle timeout will apply.

4

Just to confirm what Gary said, we do aggressively terminate duplicate Daemons that aren’t more-or-less continuously in use.

As you found and Gary suggested, making them “incompatible” is the best way to fix your situation right now as turning off our Daemon expiration mechanisms is not supported.