[IJ Plugin] `Gradle JDK location` settings are not respected which results in rogue Gradle daemons created

[scana]

Version

4.1.1

Summary

Hi! We're hosting a JDK in a custom location for our project and it seems to result with the plugin launching two separate Gradle daemons due to JDK version mismatch. The ones spawned by the plugin seems to be using default one, baked in within the IDE. I suppose this is caused by Automatic code generation. Disabling the plugin resolves the issue which is why I'm reporting it here.

For some reason both of the daemons seem to be constantly active, allocating memory, even if I keep the Android Studio inactive, see screenshots. The second one also indicates an issue with spawning too many threads (?)

Now, our project is quite big (dozens of graphql modules), but I wouldn't expect two daemons to run for so long without any visible changes in the project. I've yet to test how it does behave if a developer uses baked-in IDE JDK as then I'd assume that it would keep the main daemon constantly busy.

What	Screen
First daemon (IDE JDK)
Second daemon (IDE JDK)
Third daemon (proper JDK)
First daemon (5 min uptime)
First daemon (12 min uptime)
First daemon (22 min uptime)
Second daemon (5 min uptime)
Second daemon (12 min uptime)
Second daemon (22 min uptime)

Steps to reproduce the behavior

• Install Apollo GraphQL
• Set globally accessible variable STUDIO_GRADLE_JDK to any valid custom path containing a JDK.
• Close Android Studio
• ensure all Gradle daemons are killed
• Launch Android Studio, after a while 2 daemons with default JDK should spawn.

Repeat the same with Apollo GraphQL plugin disabled

Logs

No response

[vmadalin]

This was reported originally on https://issuetracker.google.com/issues/402033760 and affects performance in the IDE given that new Daemon JVM process has to be spawn instead of reusing potentially same as the Gradle build when possible.

In order to address this, plugin must use GradleInstallationManager.getGradleJvmPath() application service from the IDEA or equivalent to ensure that same Gradle JVM path is used by the plugin and build. At the same time, the GradleManager supports projects using Daemon JVM criteria which in that case the GradleExecutionSettings shouldn't specify the javaHome for the LongRunningOperation in order the defined criteria to take priority over the Gradle JDK configuration

In addition, seems there is a major performance impact pontetially linked to regression ?? since plugin is taking ~8GB of memory heap for one daemon and ~4GB for another daemon a side of leaking threads. Just for comparison the Android Studio uses ~8GB to sync a project with 2K modules.

[BoD]

Thanks for reporting!

A few remarks:

• For its automatic codegen feature, the plugin uses Gradle's continuous build feature, which has the effect you see of having a daemon running constantly. We're evaluating doing this differently, which is tracked in [IJ Plugin] Reconsider use Gradle's continuous mode for automatic codegen apollo-intellij-plugin#36
• The amount of memory this daemon is taking should follow the org.gradle.jvmargs value in the gradle.properties file of your project
• I am not exactly sure why you're seeing 2 daemons though (let alone 3), this is surprising and I will need to investigate, but this is probably due to not following the configured JDK as noted in the issue you linked to. Thanks for providing this issue and the information about how to do this correctly, I will have a look at it.
• In the meantime the automatic codegen feature of the plugin can be disabled (in the settings), so you can still benefit from the plugin's other features

[scana]

I am not exactly sure why you're seeing 2 daemons though (let alone 3), this is surprising and I will need to investigate, but this is probably due to not following the configured JDK as noted in the issue you linked to. Thanks for providing this issue and the information about how to do this correctly, I will have a look at it.

That 3rd daemon is expected as that's the one owned by Studio running a sync. In case of using wrong JDK I'd expect the plugin to create at most 1 additional daemon though.

The amount of memory this daemon is taking should follow the org.gradle.jvmargs value in the gradle.properties file of your project

It does follow our setting, the only difference being the JDK. This part is probably worth highlighting as a separate issue, I wouldn't expect one of the daemons to fill up so quickly (that's on an inactive project, i.e. I've opened Android Studio and just waited 20 minutes):

[vmadalin]

I have to say that might be problematic the fact that a plugin also relays on org.gradle.jvmargs, definitely this is more architecture issue of how IntelliJ plugins works. However, that value is used also for IDE to sync the project so if 8GB is specified that will mean that your plugin will also have set max heap set as 8GB considering this is just one plugin despite that not all of them will spawn daemons. So you can imagine following Android Studio recommendation that syncing a project with 16GB RAM definitely will not be enough given previously shared numbers.

[BoD]

@vmadalin maybe it would make sense to add the ability to specify a value for this in the settings, as a mitigation (while the preferred long term fix will probably be to avoid the continuous mode, or running Gradle altogether).

[BoD]

Hey @scana I pushed a fix to use the JVM location specified in the IDE settings, and also set the heap size used by the codegen daemon to -Xms64m -Xmx512 (configurable in the Apollo plugin settings).

You can try this fix using the weekly snapshots of the plugin.

This is likely not the end of the story but should improve the situation for you - feedback warmly welcome!

[BoD]

This is part of 4.2.0 which should be available in the Marketplace soon.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Kotlin usage and allow us to serve you better.