Org.gradle.daemon=false seems to be ignored


(teknopaul) #1

hi gradle seems to ignore my ~/.gradle/gradle.properties

which has

org.gradle.daemon=false
org.gradle.jvmargs=’-Xmx128m -Xshareclasses -Xss128k -XX:MaxPermSize=64m’

Starting a Gradle Daemon, 3 busy and 1 incompatible and 1 stopped Daemons could not be reused, use --status for details

It then starts 2 JVMs which use all the RAM and crash.

Has this file moved?


(James Justinic) #2

No, not if you’re using the defaults. However, if you change GRADLE_USER_HOME, Gradle will look at the gradle.properties relative to that. It’s also possible for an environment variable to override this.

Are you sure that’s the cause of the crash? That org.gradle.jvmargs is suspicious. The args are not normally quoted. The -Xshareclasses argument is not standard. 128k is extremely low for the stack size. All of these can crash the JVM.


(Stefan Oehme) #3

These JVM args don’t need to b quoted. Why are you deactivating the daemon? That’s just going to make all your builds much slower with no benefit. Also, the stack size and max perm size are a bit low and class sharing is not something that we test for, so I recommend not using it.

Note that if you specify any “org.gradle.jvmargs”, the Gradle command line client will check to make sure it matches these arguments and will start a single-use build process if it doesn’t. The client VM arguments are controlled by the environment variable GRADLE_OPTS.

I recommend setting GRADLE_OPTS to something small like 32-64M (the client only handles some logging in daemon mode), using the daemon and giving it enough resources (standard stack size, at least 64m permgen space and at least 64m heap). The gradle.properties should be set on a project level, not at the user level, since every project will have different requirements. That way you can keep it low for small projects, but spawn a big daemon if you have some large project.


(teknopaul) #4

its cordova maybe that env var is set.
I want to stop the deamon because it runs in a jvm and I run our of RAM. 512m onthe box.
-Xss128 stack is standard in our big prod environments, 1M per is a killer with multi threaded servers, you get OOME if you hit it so thats not the issue.
Ill unquotes the args perhaps that’s a problem.
But the real issue is starting two jvms with only 512 mof ram.
-Xshareclasses I set whenever I have two jvms in the same vm. When you boot the second jvm some memory is shared. It would not matter if there were one.
This box did app builds with cordova and Ant before graddle was involved.
Thanks for the tips.


(Stefan Oehme) #5

Even with 512m, there is no reason to deactivate the daemon. You just need to give it less memory, appropriate for your application. And you need to keep the client VM small (since it only does logging when the daemon is used).

You might wonder why we don’t give the client VM very little memory by default. This is for historical reasons, because in no-daemon mode (and when no conflicting jvmargs are set) the client will perform the build itself. So by default it will request 1g of RAM, just like the daemon’s default. This mode is rarely used nowadays, so we’ll probably change up the defaults in the next major version.