[Android Studio] Apollo IDE plugin spawns a daemon in 'BUSY' that will not stop

[agrosner]

Version

5.0.0

Summary

Enable the apollo IDE plugin. Sync project in Android studio in a large project (~500 modules). Observe that a daemon is open and BUSY. Run the project, and a second daemon is spun up and they begin thrashing with each other. Deactivating the plugin directly stops the gradle daemon. The daemon is started with the same global gradle ops.

org.gradle.jvmargs=-Xmx32g -XX:+UseParallelGC -XX:MaxMetaspaceSize=16g -XX:-UseGCOverheadLimit

Kotlin Lang thread

Ive also tried setting the custom options in apollo plugin settings with a smaller memory arg, but this is not affected by it.

If i manually kill the daemon, it restarts IMMEDIATELY. It never goes away as long as plugin is active and consumes nearly as much CPU as building the project and starves memory on the computer. so they end up thrashing with one another.

Steps to reproduce the behavior

No response

Logs

(Your logs here)

[BoD]

I think that's actually expected:

• Android Studio runs a task to compile your project
• at the same time, the Apollo plugin runs tasks to get the project's configuration, and to run the codegen

When these 2 things happen at the same time 2 daemons need to be started.

Later on when these tasks have finished, the daemons can stop after the idle timeout (5 minutes).

Keeping the Apollo plugin "additional Gradle JVM argument" empty can actually be beneficial because existing daemons with different arguments can't be re-used. By keeping it empty you maximize the chance of re-using the daemon created by Android Studio.

Let me know if that makes sense.

---

That being said, we do have an improvement that should avoid more Gradle daemon being started, which is to run the codegen directly from the plugin (rather than through Gradle). This works on projects using Apollo Kotlin v5+ (currently in alpha).

[agrosner]

Later on when these tasks have finished, the daemons can stop after the idle timeout (5 minutes). the issue is that the daemon does not stop. it remains in Busy state well past the 5 minutes. The daemon that is spun up is ignoring the IDE gradle options, so its taking up my global configuration of 32G.

[agrosner]

i wouldnt mind if it was using the correct configuration and timed out 5 mins or less (when it completed its work). but its taking up 32g without a way to limit it.

[BoD]

The issue is that the daemon does not stop. it remains in Busy state well past the 5 minutes.

I am guessing that it actually takes a lot of time to retrieve the configuration, which unfortunately has to be done by executing a specific task on each module one by one. You said your project has >500 modules, but how many of these apply the Apollo Kotlin plugin?

Also may I ask how long does it usually take to run the generateApolloSources task?

The daemon that is spun up is ignoring the IDE gradle options, so its taking up my global configuration of 32G

That was actually expected, as the arguments were only be used when executing the codegen, and not when fetching the configuration. I've just opened #86 to fix that.

[agrosner]

I am guessing that it actually takes a lot of time to retrieve the configuration, which unfortunately has to be done by executing a specific task on each module one by one. You said your project has >500 modules, but how many of these apply the Apollo Kotlin plugin?

58 modules.

Also may I ask how long does it usually take to run the generateApolloSources task?

we have two service schemas - a federated one, and a monolith php. It takes ~1 min to generate apollo sources.
so its remaining stuck past its point. and then the regular runner cannot reuse it.

[agrosner]

what gradle config does it respect, project level or global level, or ?

[agrosner]

for context, I have a global gradle config i use to override my project's gradle config. would that be a cause?

[BoD]

Thanks for the additional info!

58 modules is a lot and I am guessing that the daemon can be busy for more than 5 minutes indeed, while fetching the configuration models. But this should eventually finish of course.

If you want to confirm that this is what's keeping the daemon busy, and to get an idea of how long this should take, you can add Apollo to Help | Diagnostic Tools | Debug Log Settings and then monitor idea.log. You should see a bunch of logs with Fetch tooling model for xyz, and then a log starting with allToolingModels= when this is over.

The PR mentioned above has been merged and will be part of the next snapshot (these are published during the week-end). Please consult this page to use the plugin's snapshots. With that version the daemon should use the values you provide in the settings when fetching the configuration.

[BoD]

what gradle config does it respect, project level or global level, or ?

This uses the API provided by the IDE to invoke Gradle, so you should see the same as what's used when running a build. To be honest I thought the project configuration would override the global one so... I'm not sure which one it's supposed to use 😅

But with the above PR, the arguments you put in the plugin's settings will be used.

[BoD]

This is also now released in v5.0.1 of the plugin - feel free to let me know if that improves the situation.

[kenyee]

@BoD : we're trying this new plugin param and it seems to append it to the existing jvmargs we specified in our gradle properties.

So we get -Xms and "-Xms2g" from the plugin config in the UI.
Seems like a bug? It should replace the existing gradle.properties setting because most apps will have a relatively high number to build everything including lint, etc.