Fix java 21 build

[wetted]

Supersedes #415 to stop micronaut-build force pushing it all the time

[timyates]

Looks like this has been failing for a while https://ge.micronaut.io/scans/tests?search.timeZoneId=Europe%2FLondon&tests.container=io.micronaut.testresources.server.TestResourcesControllerTest&tests.test=verifies%20that%20server%20can%20instantiate%20container

[timyates]

@sdelamo This change seems to be where this error began: e9a0b15

[timyates]

I've reverted that commit. An import wasn't required (as the class is in the same package) and the commit changed the class that was returned to the wrong one

[timyates]

This test seems to hang under Java 21 🤔

micronaut-test-resources/test-resources-server/src/test/groovy/io/micronaut/testresources/server/TestResourcesControllerTest.groovy

Line 79 in 5917a0e

client.resolve("kafka.bootstrap.servers", [:], [:])

@melix any ideas?

[melix]

No I don't.

[timyates]

Found it... PR incoming... Lock issue I think

[timyates]

Ok, so the issue was that under Java 21 the controller switches to using virtual executors.

Inside TestContainers we use a re-entrant lock and this all worked as it was effectively the same thread making all the requests

10:44:44.911 [io-executor-thread-1] TRACE i.m.t.testcontainers.TestContainers - Unlocked for getOrCreate
10:44:44.911 [io-executor-thread-1] DEBUG i.m.t.server.TestResourcesController - Attempt to resolve kafka.bootstrap.servers with resolver class io.micronaut.testresources.kafka.KafkaTestResourceProvider, properties {} and test resources configuration {} : PLAINTEXT://127.0.0.1:50708
10:44:44.920 [io-executor-thread-1] TRACE i.m.t.testcontainers.TestContainers - Locked for listByScope
10:44:44.920 [io-executor-thread-1] TRACE i.m.t.testcontainers.TestContainers - Unlocked for listByScope
10:44:44.927 [io-executor-thread-1] DEBUG i.m.t.server.TestResourcesController - Closing all test resources
10:44:44.927 [io-executor-thread-1] TRACE i.m.t.testcontainers.TestContainers - Locked for closeAll
10:44:45.076 [io-executor-thread-1] TRACE i.m.t.testcontainers.TestContainers - Unlocked for closeAll
10:44:45.085 [io-executor-thread-1] TRACE i.m.t.testcontainers.TestContainers - Locked for listByScope
10:44:45.085 [io-executor-thread-1] TRACE i.m.t.testcontainers.TestContainers - Unlocked for listByScope

But with Java 21, we're seeing a new thread per request, and this is causing issues as re-entrant lock will not let these other thread in if it hasn't been unlocked

10:50:33.676 [virtual-executor4] TRACE i.m.t.testcontainers.TestContainers - Locked for listByScope
10:50:33.676 [virtual-executor4] TRACE i.m.t.testcontainers.TestContainers - Unlocked for listByScope
10:50:33.693 [virtual-executor5] DEBUG i.m.t.server.TestResourcesController - Closing all test resources
10:50:33.693 [virtual-executor5] TRACE i.m.t.testcontainers.TestContainers - Locked for closeAll
10:50:33.830 [virtual-executor5] TRACE i.m.t.testcontainers.TestContainers - Unlocked for closeAll
10:50:33.833 [virtual-executor6] TRACE i.m.t.testcontainers.TestContainers - Locked for listByScope
10:50:33.834 [virtual-executor6] TRACE i.m.t.testcontainers.TestContainers - Unlocked for listByScope

I think this is fixed by ensuring all LOCK/UNLOCK couplets are in a try...finally

We could also force java 17 behavior by using @ExecuteOn(IO) in the controller methods...

But I think checking the locks are unlocked is the more correct behavior...

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

100.0% Coverage
0.0% Duplication