-
Notifications
You must be signed in to change notification settings - Fork 668
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[IJ Plugin] Gradle JDK location
settings are not respected which results in rogue Gradle daemons created
#6418
Comments
Gradle JDK location
settings are not respected which results in rogue Gradle daemonsGradle JDK location
settings are not respected which results in rogue Gradle daemons created
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 In addition, seems there is a major performance impact pontetially linked to regression ?? since plugin is taking |
Thanks for reporting! A few remarks:
|
I have to say that might be problematic the fact that a plugin also relays on |
@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). |
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.
Steps to reproduce the behavior
STUDIO_GRADLE_JDK
to any valid custom path containing a JDK.Repeat the same with Apollo GraphQL plugin disabled
Logs
No response
The text was updated successfully, but these errors were encountered: