Gradle startup failure due to network change

Old Forum Archive
1

Using gradle on my laptop (which is rebooted about one or two times a week, rest is just suspend-to-disk) I have gradle failures that seem to be related to network changes.

Resuming the machine and connect to a different WLAN AP or ethernet I get failures like this:

FAILURE: Build failed with an exception.
  * What went wrong:
Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at http://gradle.org/docs/1.6/userguide/gradle_daemon.html
Please read below process output to find out more:
-----------------------
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

gradle --stop says that no daemons are running and I don’t see any java processes. Now when I change the access point gradle runs. Changing the access point back (to the failing) one: gradle works. I also deleted everything under .gradle, which has no effect.

Are there any other locks or system wide objects that gradle creates ? Or is this some kind of JVM cache (but eclipse, ant etc. work without problems) ?

Thanks.

2

The daemon JVM is failing to start at all because there isn’t enough memory.

Do you know if this is legitimate? That is, there is little available memory available at the time?

3

It is a 64bit windows running a 32bit JVM, no special org.gradle.jvmargs or env variable settings. The laptop has 24GB physical memory, but this shouldn’t be related since the JVM should always get enough virtual address space due to 64bit OS. After several such errors I also doubt that the network change is really the problem, I think it was more of a change in system settings that triggered something to change (but I don’t know what). Other java tools (like ant, eclipse) startup without problems, so it doesn’t seem that the JVM has a problem to start.