The newly created daemon process has a different context than expected

Help/Discuss
1

Hello good people. I am using the Gradle Tooling API from a custom Java application to analyze code in git repositories cloned to other folders on the disk.

When creating a ProjectConnection to a Gradle project using the Java and Gradle version as the application running itself there is no problem. When attempting to make a Gradle Connection using a different Java version the Tooling API seems to return the wrong daemon instead creating a correct one.

Note: I manually close all daemons using “./gradlew --stop” between each GradleProjection conection initalization. So there should be no active daemons running. This is an attempt to fix the problem.

Can anyone guide me to why the Tooling API would return the wrong daemon. Clearly some parts of the code knows which JDK it should be using, but the “daemon creation logic” determines something else.

Error from application run:

13:53:38 Caused by: org.gradle.launcher.daemon.client.DaemonConnectionException: The newly created daemon process has a different context than expected. 
13:53:38 It won't be possible to reconnect to this daemon. Context mismatch: 
13:53:38 Java home is different.
13:53:38 Wanted: DefaultDaemonContext[uid=null,javaHome=/usr/lib/jvm/java-1.8-openjdk,daemonRegistryDir=/home/jenkins/.gradle/daemon,pid=529,idleTimeout=null,priority=NORMAL,daemonOpts=--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.base/java.lang=ALL-UNNAMED,--add-opens,java.base/java.lang.invoke=ALL-UNNAMED,--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.base/java.nio.charset=ALL-UNNAMED,--add-opens,java.base/java.net=ALL-UNNAMED,--add-opens,java.base/java.util.concurrent.atomic=ALL-UNNAMED,-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant] 
13:53:38 Actual: DefaultDaemonContext[uid=03828697-4412-444c-b413-50fba937c7e9,javaHome=/opt/java/openjdk,daemonRegistryDir=/home/jenkins/.gradle/daemon,pid=1899,idleTimeout=5000,priority=NORMAL,daemonOpts=--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.base/java.lang=ALL-UNNAMED,--add-opens,java.base/java.lang.invoke=ALL-UNNAMED,--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.base/java.nio.charset=ALL-UNNAMED,--add-opens,java.base/java.net=ALL-UNNAMED,--add-opens,java.base/java.util.concurrent.atomic=ALL-UNNAMED,-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]
2

As it speaks about “newly created daemon process”, I don’t think stopping all daemons or not has an impact.

Actually, just in case you are not aware, ./gradlew --stop does not stop all daemons, but only the daemons for the same Gradle version.

The message tells you that “Java home is different” and that wanted is “/usr/lib/jvm/java-1.8-openjdk” while actual is “/opt/java/openjdk”.

So maybe have a look at those two directories.
I guess one is a symlink to the other.
So maybe that is the problem.
Whether this is a bug in the daemon context recognition or whether you start it differently I don’t know, it is just an idea what could cause the issue.

3

Thanks for the reply. Unfortunately it is a little more complex.

Stopping the gradle daemons after handling the analysis of every single repository should result in no daemons running when starting working on a new repository.

The …/java-1.8-openjdk is a link but to a plain directory.
And the /opt/java/openjdk is a normal directory as well, but also the value of JAVA_HOME which is why I think Gradle is falling back to it.

Can’t gradle follow symlinks ?
Here is the /usr/lib/java

09:31:45  drwxr-xr-x    4 root     root            94 Apr 13 11:28 .
09:31:45  drwxr-xr-x    1 root     root          8192 Apr 13 11:28 ..
09:31:45  lrwxrwxrwx    1 root     root            15 Apr 13 11:28 default-jvm -> java-11-openjdk
09:31:45  drwxr-xr-x    6 root     root           136 Apr 13 11:28 java-1.8-openjdk
09:31:45  drwxr-xr-x   10 root     root           188 Apr 13 11:28 java-11-openjdk
09:31:45  lrwxrwxrwx    1 root     root            16 Apr 13 11:28 java-8-openjdk -> java-1.8-openjdk

and the /opt/java

09:31:45  drwxr-xr-x    1 root     root            17 Mar 29 21:50 openjdk
4

should result in no daemons running when starting working on a new repository

Your output shows that a new daemon is indeed started.

Can’t gradle follow symlinks ?

I don’t know, I would expect it to handle it properly.
But as you showed, /usr/lib/java/java-1.8-openjdk and /opt/java/openjdk are both not symlinks but own directories (or hard-links which is the same in that regard).
So there is nothing to follow for Gradle.

Why the started daemon does use a different JDK than exepcted, I have no idea.
If you can knit a reproducer that shows that Gradle is behaving wrong and not you calling something funky, you should open a bug ticket with it.
As long as it is only reproducible on your machine, it is hard to report or fix, so you might need to debug the logic on your machine.