Open gsmet opened 3 weeks ago
/cc @geoand (kubernetes,minikube), @iocanel (kubernetes)
/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.
https://github.com/quarkusio/quarkus/pull/40942#issuecomment-2171657096 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 QuarkusTest
? Since shortly, we experience inconsistent classloader issues when running QuarkusTests within the scope of the actual test class, of which we are still confused.
java.util.concurrent.ExecutionException: java.lang.ClassCastException: class com.company.MyClass cannot be cast to class com.company.MyClass (com.company.MyClass is in unnamed module of loader 'app'; com.company.MyClass is in unnamed module of loader io.quarkus.bootstrap.classloading.QuarkusClassLoader @3aeba81)
Can this cause classloader issues during
QuarkusTest
? Since shortly, we experience inconsistent classloader issues when running QuarkusTests within the scope of the actual test class, of which we are still confused.
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.
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.operationComplete
This 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.warn
io.netty.util.concurrent.GlobalEventExecutor.startThread
And related:
io.micrometer.core.instrument.binder.jvm.JvmHeapPressureMetrics
This is due to this piece of code in
ClassTransformingBuildStep
(usage ofcl
):DevUIGrpcSmokeTest
Hard to figure out what's going wrong here as we don't have the stacktraces handy.
:white_check_mark: This one has been solved by a follow up commit.
:white_check_mark: This one has been solved by a follow up commit.