Class Loader still used while it's supposed to be closed #41233
Labels
Comments
|
/cc @dmlloyd @cescoffier I think your feedback will be invaluable here too. |
|
There is a hack iterating over Vert.x event loops to reset the TCCL in dev mode. That might be the problem. |
|
#40942 (comment) might also be related |
|
We are very cavalier about how we create and use class loaders. Since we don't have any kind of determinism around them, we end up with non-deterministic consequences. Throwing an exception is a good start, but troubleshooting these problems is going to be pretty tricky I suspect. |
|
Can this cause classloader issues during |
No, more likely you need #40906 for this one, but it's just a guess based on this small snippet. Once that PR is merged, if you still have an issue, then consider filing a bug or opening a discussion topic for it. |
gsmet
added a commit
to gsmet/quarkus
that referenced
this issue
Jun 25, 2024
When popping provider factory, what we actually want is pop it if something has been pushed. It is better handled by setting a boolean if something has been pushed. This allows class loading issues when the class loader has been closed and the request is still processing. Related to quarkusio#41233
gsmet
added a commit
to gsmet/quarkus
that referenced
this issue
Jun 25, 2024
And also avoid passing the CuratedApplication here. The problem was noticed when trying to log something in the QuarkusClassLoader constructor. Related to quarkusio#41233
gsmet
added a commit
to gsmet/quarkus
that referenced
this issue
Jun 25, 2024
- The TestResourceManager is instantiated using the runtime class loader so we need to make sure we close it before we close the runtime class loader. Otherwise we can get into trouble if we need to load some additional classes. - Also make sure that it is only closed once. It used to be closed once when the application is stopped and then again when the QuarkusTestExtensionState was closed. Related to quarkusio#41233
gsmet
added a commit
to gsmet/quarkus
that referenced
this issue
Jun 25, 2024
Currently, we pass the CL to something that will close it, rather than controlling the lifecycle in the creator method. This is an issue in native ITs: java.lang.RuntimeException: java.lang.IllegalStateException: This class loader has been closed at io.quarkus.test.junit.QuarkusIntegrationTestExtension.throwBootFailureException(QuarkusIntegrationTestExtension.java:373) at io.quarkus.test.junit.QuarkusIntegrationTestExtension.beforeEach(QuarkusIntegrationTestExtension.java:117) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) Caused by: java.lang.IllegalStateException: This class loader has been closed at io.quarkus.bootstrap.classloading.QuarkusClassLoader.ensureOpen(QuarkusClassLoader.java:716) at io.quarkus.bootstrap.classloading.QuarkusClassLoader.loadClass(QuarkusClassLoader.java:495) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:467) at io.quarkus.runner.bootstrap.AugmentActionImpl.performCustomBuild(AugmentActionImpl.java:158) at io.quarkus.test.junit.IntegrationTestUtil.handleDevServices(IntegrationTestUtil.java:297) at io.quarkus.test.junit.QuarkusIntegrationTestExtension.doProcessStart(QuarkusIntegrationTestExtension.java:199) at io.quarkus.test.junit.QuarkusIntegrationTestExtension.ensureStarted(QuarkusIntegrationTestExtension.java:169) at io.quarkus.test.junit.QuarkusIntegrationTestExtension.beforeAll(QuarkusIntegrationTestExtension.java:130) Related to quarkusio#41233
This was referenced Jun 25, 2024
holly-cummins
pushed a commit
to holly-cummins/quarkus
that referenced
this issue
Jul 31, 2024
Currently, we pass the CL to something that will close it, rather than controlling the lifecycle in the creator method. This is an issue in native ITs: java.lang.RuntimeException: java.lang.IllegalStateException: This class loader has been closed at io.quarkus.test.junit.QuarkusIntegrationTestExtension.throwBootFailureException(QuarkusIntegrationTestExtension.java:373) at io.quarkus.test.junit.QuarkusIntegrationTestExtension.beforeEach(QuarkusIntegrationTestExtension.java:117) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) Caused by: java.lang.IllegalStateException: This class loader has been closed at io.quarkus.bootstrap.classloading.QuarkusClassLoader.ensureOpen(QuarkusClassLoader.java:716) at io.quarkus.bootstrap.classloading.QuarkusClassLoader.loadClass(QuarkusClassLoader.java:495) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:467) at io.quarkus.runner.bootstrap.AugmentActionImpl.performCustomBuild(AugmentActionImpl.java:158) at io.quarkus.test.junit.IntegrationTestUtil.handleDevServices(IntegrationTestUtil.java:297) at io.quarkus.test.junit.QuarkusIntegrationTestExtension.doProcessStart(QuarkusIntegrationTestExtension.java:199) at io.quarkus.test.junit.QuarkusIntegrationTestExtension.ensureStarted(QuarkusIntegrationTestExtension.java:169) at io.quarkus.test.junit.QuarkusIntegrationTestExtension.beforeAll(QuarkusIntegrationTestExtension.java:130) Related to quarkusio#41233
holly-cummins
pushed a commit
to holly-cummins/quarkus
that referenced
this issue
Jul 31, 2024
- The TestResourceManager is instantiated using the runtime class loader so we need to make sure we close it before we close the runtime class loader. Otherwise we can get into trouble if we need to load some additional classes. - Also make sure that it is only closed once. It used to be closed once when the application is stopped and then again when the QuarkusTestExtensionState was closed. Related to quarkusio#41233
holly-cummins
pushed a commit
to holly-cummins/quarkus
that referenced
this issue
Jul 31, 2024
When popping provider factory, what we actually want is pop it if something has been pushed. It is better handled by setting a boolean if something has been pushed. This allows class loading issues when the class loader has been closed and the request is still processing. Related to quarkusio#41233
|
|
danielsoro
pushed a commit
to danielsoro/quarkus
that referenced
this issue
Sep 20, 2024
Currently, we pass the CL to something that will close it, rather than controlling the lifecycle in the creator method. This is an issue in native ITs: java.lang.RuntimeException: java.lang.IllegalStateException: This class loader has been closed at io.quarkus.test.junit.QuarkusIntegrationTestExtension.throwBootFailureException(QuarkusIntegrationTestExtension.java:373) at io.quarkus.test.junit.QuarkusIntegrationTestExtension.beforeEach(QuarkusIntegrationTestExtension.java:117) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) Caused by: java.lang.IllegalStateException: This class loader has been closed at io.quarkus.bootstrap.classloading.QuarkusClassLoader.ensureOpen(QuarkusClassLoader.java:716) at io.quarkus.bootstrap.classloading.QuarkusClassLoader.loadClass(QuarkusClassLoader.java:495) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:467) at io.quarkus.runner.bootstrap.AugmentActionImpl.performCustomBuild(AugmentActionImpl.java:158) at io.quarkus.test.junit.IntegrationTestUtil.handleDevServices(IntegrationTestUtil.java:297) at io.quarkus.test.junit.QuarkusIntegrationTestExtension.doProcessStart(QuarkusIntegrationTestExtension.java:199) at io.quarkus.test.junit.QuarkusIntegrationTestExtension.ensureStarted(QuarkusIntegrationTestExtension.java:169) at io.quarkus.test.junit.QuarkusIntegrationTestExtension.beforeAll(QuarkusIntegrationTestExtension.java:130) Related to quarkusio#41233
danielsoro
pushed a commit
to danielsoro/quarkus
that referenced
this issue
Sep 20, 2024
- The TestResourceManager is instantiated using the runtime class loader so we need to make sure we close it before we close the runtime class loader. Otherwise we can get into trouble if we need to load some additional classes. - Also make sure that it is only closed once. It used to be closed once when the application is stopped and then again when the QuarkusTestExtensionState was closed. Related to quarkusio#41233
danielsoro
pushed a commit
to danielsoro/quarkus
that referenced
this issue
Sep 20, 2024
When popping provider factory, what we actually want is pop it if something has been pushed. It is better handled by setting a boolean if something has been pushed. This allows class loading issues when the class loader has been closed and the request is still processing. Related to quarkusio#41233
|
It seems this one has been already resolved, Can we close it? @gsmet |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As part of my work trying to improve the CL situation, I stumbled upon a few cases of $TITLE for which I would need some help.
In my patch, I introduce a safe guard throwing an exception when you are trying to load a class from a CL that has been previously closed.
The rationale is that we shouldn't load any class from a CL that has been closed.
I already fixed a few of these problems... but I still have some going on that are a lot less easy to pinpoint.
These issues where all observed in this specific CI job run: https://github.com/gsmet/quarkus/actions/runs/9535653448/job/26281846636
io.vertx.core.impl.VertxImpl$1.operationCompleteThis one is due to the delay to handle the graceful shutdown:
From
io.vertx.core.impl.VertxImpl:A more complete stacktrace:
io.quarkus.netty.deployment.JBossNettyLoggerFactory$JBossNettyInternalLogger.warnio.netty.util.concurrent.GlobalEventExecutor.startThreadAnd related:
io.micrometer.core.instrument.binder.jvm.JvmHeapPressureMetricsThis is due to this piece of code in
ClassTransformingBuildStep(usage ofcl):DevUIGrpcSmokeTestHard to figure out what's going wrong here as we don't have the stacktraces handy.
✅ This one has been solved by a follow up commit.
✅ This one has been solved by a follow up commit.
Got it with Stork:
Also got it with REST Client:
The text was updated successfully, but these errors were encountered: