https://kotlinlang.org logo
Join Slack
Powered by
I have a build (gradle) that often stalls with: ``...
# getting-started
h
I have a build (gradle) that often stalls with:
Copy code
2023-03-29T14:18:30.913+0200 [DEBUG] [org.gradle.internal.resources.AbstractTrackedResourceLock] Daemon worker: acquired lock on worker lease
2023-03-29T14:18:30.913+0200 [DEBUG] [org.gradle.internal.resources.AbstractTrackedResourceLock] Daemon worker: released lock on worker lease
2023-03-29T14:18:36.716+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2023-03-29T14:18:36.716+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2023-03-29T14:18:36.716+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2023-03-29T14:18:36.716+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2023-03-29T14:18:36.716+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2023-03-29T14:18:36.716+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2023-03-29T14:18:46.716+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2023-03-29T14:18:46.716+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2023-03-29T14:18:46.716+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2023-03-29T14:18:46.716+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2023-03-29T14:18:46.716+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2023-03-29T14:18:46.716+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
<=========----> 69% EXECUTING [9m 50s]
> :server:compileTestKotlin
Is there some way to diagnose this? Iam running it like this 
gradle -d -S -Dorg.gradle.java.home=/usr/lib/jvm/java-19-openjdk
already but there is nothing else coming out to give any hints on why it stalls. The total build is just around a couple of minutes max usually including test suite.
s
I have seen issues like this when running multiple gradle builds in the same directory
h
This happens when just running this build and nothing else
😢 1
v
The output is nothing unusual. If you can reproduce this, you should probably run it through a debugger and then look at a thread dump when it "stalls" to see what is happening or where it is hanging.
h
I did but visualvm didn't catch much although it has been a while since I properly used it
Not even sure if it's the kotlin compiler or gradle deamon that is the problem
Btw are the gradle dsl always incompatible even between minor versions?
I can't upgrade to 7.6.1 from 7.5.1 because it blows up
v
If you scratch the "in" from "incompatible" it is correct. Breaking changes (except erroneous ones, or on incubating things) are only done on major version changes.
h
Well I can't upgrade from 7.5.1 to 7.6.0 which is what you say should be supported or am I not getting how it works?
v
I don't know because gave no hint at all as to what your problem is / which error you got, and my crystal ball is at the repair shop unfortunately. 🙂
An upgrade within the same major version should usually always work wihtout problem
h
I got past it it was a minor thing
v
What was it?
h
Not sure why the upgrade didn't work
Copy code
suites {
        val integrationTest by registering(JvmTestSuite::class) {
            testType.set(TestSuiteType.INTEGRATION_TEST)
            useJUnitJupiter()
            dependencies {
                //implementation(project)
The commented "implementation" did the trick but perhaps something else will break
v
Yeah, taht is an incubating API, so as I said, there indeed can be breaking changes and indeed in 7.6 there was one which made the dependency declarations in that block typed and better usable from Kotlin DSL.
h
Aha! Thx for clarifying
Doesn't seem to help with the stalls however
I thought I should report back. It was not a stall but a compiler error that simply took the compiler so very long to work out. A data class that was changed to contain a new mandatory field. Naturally that broke a number of tests which didn't have this field. The process finished after almost 18 minutes with perhaps a dozen "missing field" errors. There seems to be a non linear deterioration because fixing half the instances cut the time more than four times and so on progressively down to normal times. Not sure what to expect but but this isn't it. It's should really go much faster to bail out on this imho.
👌 1
708 Views
Open in Slack
PreviousNext
Powered by