This message was deleted.
# community-support
s
This message was deleted.
👀 1
t
Depending on what you need to run, build services can be an option: https://docs.gradle.org/current/userguide/build_services.html Otherwise then yes, use a separate Gradle run (I believe it uses the same daemon though, it only blocks the client)
Fwiw, Kotlin/JS does such a thing as a "long running task" though (https://kotlinlang.org/docs/dev-server-continuous-compilation.html). Last time I checked, they were using an internal Gradle API for that.
i
I have multiple JVM (Kotlin) micro-services that communicate with each other. Currently we use IntelliJ run configurations to start them, so each of them requests the build from the daemon, and IntelliJ does the execution (freeing the daemon). We have issues with JDK versions, so we're considering executing everything via the application plugin to use java toolchains. I'm worried this will make builds slower as each module will need its own daemon (since the daemon gets stuck executing the service)
t
Fwiw, Kotlin/JS does such a thing as a "long running task" though […]. Last time I checked, they were using an internal Gradle API for that.
This is still the case: https://github.com/JetBrains/kotlin/blob/9324cf336090deb5292282a512c1c0618a8b0774/[…]org/jetbrains/kotlin/gradle/targets/js/webpack/KotlinWebpack.kt
I'm worried this will make builds slower as each module will need its own daemon (since the daemon gets stuck executing the service)
I'm really not sure this is the case. AFAIK, only the client is blocked, waiting for the run task to finish; the same daemon is used for everything though.
i
Is there a way to check this?
t
Run two such tasks in distinct Gradle invocations, and: • look if Gradle says it needs to run a new daemon because the previous one cannot be used • use
./gradlew --status
and/or
jps
or
ps
to tell how many daemons are being used
i
I just checked, and you're right, even if the client is stuck on a
run
task, no new daemon is started (as long as you wait for the build to finish before starting a new task, of course)
t
I just tried and it looks like I was actually _wrong_: the daemon for the first build is considered "busy" and a new one is started for the second build. That said, up-to-date checks still make the builds fast, and a Gradle daemon is not that expensive to start (YMMV)
i
🤔 That's strange, when I tested it it definitely did not start new daemons (or they were killed at the of the build)
t
To be clear on what I did test: • in one terminal:
./gradlew :service-a:run
(an application that starts an embedded Jetty server) • in another:
./gradlew :service-b:run
(same kind of app with an embedded Jetty server); Gradle prints that a new daemon is started as another one is busy • in a third terminal:
./gradlew --status
shows 2 busy daemons I did not “wait for the build to finish before starting a new task”; the two applications are running in parallel. note: this is a project that's still using Gradle 7.1; things might possibly be different in newer versions.
i
I did the same but waited until the first web server was running before starting the second task, then it reuses the first daemon. I'm using 7.2 so I doubt it's very different
t
Ah yes, I did wait for the first one to be running too (I don't consider that as "wait for the build to finish", as I consider the run task to be part of the build). Anyway, if your own tests show that it matches your expectations, then feel free to ignore mine 😄