eclipse-store
Bootloader issues with Quarkus
Environment Details
- EclipseStore Version: 1.2.0
- JDK version: 21
- OS: Mac OS
- Used frameworks:Quarkus 3.8.1
Describe the bug
Explained here https://stackoverflow.com/questions/65898882/quarkus-with-microstream-classloader-problems, we have to set the Classpath provider to be able to run with Quarkus:
EmbeddedStorageConfigurationBuilder.New()
// default is "ClassLoader.getSystemClassLoader()"
.onConnectionFoundation(cf -> cf.setClassLoaderProvider(ClassLoaderProvider.New(Thread.currentThread().getContextClassLoader())))
..
.start();
After setting the ClassLoaderProvider to Thread.currentThread().getContextClassLoader()), EclipseStore will run in Quarkus. However, the Classloader issue is not fully resolved, when starting Quarkus in dev-mode:
Reproducer:
- Start Quarkus in dev-mode (
clean compile quarkus:dev) - Change any file so that quarkus:dev refreshes
- The following error log is shown:
2024-03-03 04:09:06,651 ERROR [io.qua.dep.dev.IsolatedDevModeMain] (vert.x-worker-thread-1) Failed to start quarkus: io.quarkus.dev.appstate.ApplicationStartException: java.lang.RuntimeException: Failed to start quarkus
at io.quarkus.dev.appstate.ApplicationStateNotification.waitForApplicationStart(ApplicationStateNotification.java:58)
at io.quarkus.runner.bootstrap.StartupActionImpl.runMainClass(StartupActionImpl.java:132)
at io.quarkus.deployment.dev.IsolatedDevModeMain.restartApp(IsolatedDevModeMain.java:192)
at io.quarkus.deployment.dev.IsolatedDevModeMain.restartCallback(IsolatedDevModeMain.java:173)
at io.quarkus.deployment.dev.RuntimeUpdatesProcessor.doScan(RuntimeUpdatesProcessor.java:541)
at io.quarkus.deployment.dev.RuntimeUpdatesProcessor.doScan(RuntimeUpdatesProcessor.java:441)
at io.quarkus.vertx.http.runtime.devmode.VertxHttpHotReplacementSetup$5.call(VertxHttpHotReplacementSetup.java:150)
at io.quarkus.vertx.http.runtime.devmode.VertxHttpHotReplacementSetup$5.call(VertxHttpHotReplacementSetup.java:137)
at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$0(ContextImpl.java:177)
at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:276)
at io.vertx.core.impl.ContextImpl.lambda$internalExecuteBlocking$2(ContextImpl.java:209)
at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538)
at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.RuntimeException: Failed to start quarkus
at io.quarkus.runner.ApplicationImpl.doStart(Unknown Source)
at io.quarkus.runtime.Application.start(Application.java:101)
at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:111)
at io.quarkus.runtime.Quarkus.run(Quarkus.java:71)
at io.quarkus.runtime.Quarkus.run(Quarkus.java:44)
at io.quarkus.runtime.Quarkus.run(Quarkus.java:124)
at io.quarkus.runner.GeneratedMain.main(Unknown Source)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at io.quarkus.runner.bootstrap.StartupActionImpl$1.run(StartupActionImpl.java:113)
... 1 more
Caused by: java.lang.ClassCastException: class app.data.Root cannot be cast to class app.data.Root (app.data.Root is in unnamed module of loader io.quarkus.bootstrap.classloading.QuarkusClassLoader @6a0659ac; app.data.Root is in unnamed module of loader io.quarkus.bootstrap.classloading.QuarkusClassLoader @2c135f49)
...
at io.App_Bean.doCreate(Unknown Source)
at io.App_Bean.create(Unknown Source)
at io.App_Bean.create(Unknown Source)
at io.quarkus.arc.impl.AbstractSharedContext.createInstanceHandle(AbstractSharedContext.java:119)
at io.quarkus.arc.impl.AbstractSharedContext$1.get(AbstractSharedContext.java:38)
at io.quarkus.arc.impl.AbstractSharedContext$1.get(AbstractSharedContext.java:35)
at io.quarkus.arc.impl.LazyValue.get(LazyValue.java:32)
at io.quarkus.arc.impl.ComputingCache.computeIfAbsent(ComputingCache.java:69)
at io.quarkus.arc.impl.ComputingCacheContextInstances.computeIfAbsent(ComputingCacheContextInstances.java:19)
at io.quarkus.arc.impl.AbstractSharedContext.get(AbstractSharedContext.java:35)
at io.App_Bean.get(Unknown Source)
at io.App_Bean.get(Unknown Source)
at io.quarkus.arc.impl.ArcContainerImpl.beanInstanceHandle(ArcContainerImpl.java:554)
at io.quarkus.arc.impl.ArcContainerImpl.beanInstanceHandle(ArcContainerImpl.java:534)
at io.quarkus.arc.impl.ArcContainerImpl.beanInstanceHandle(ArcContainerImpl.java:567)
at io.quarkus.arc.impl.ArcContainerImpl.instance(ArcContainerImpl.java:339)
at io.App_Observer_Synthetic_wKazinfVTztwl6u625c5_wlQFVE.notify(Unknown Source)
at io.quarkus.arc.impl.EventImpl$Notifier.notifyObservers(EventImpl.java:346)
at io.quarkus.arc.impl.EventImpl$Notifier.notify(EventImpl.java:328)
at io.quarkus.arc.impl.EventImpl.fire(EventImpl.java:82)
at io.quarkus.arc.runtime.ArcRecorder.fireLifecycleEvent(ArcRecorder.java:155)
at io.quarkus.arc.runtime.ArcRecorder.handleLifecycleEvents(ArcRecorder.java:106)
at io.quarkus.deployment.steps.LifecycleEventsBuildStep$startupEvent1144526294.deploy_0(Unknown Source)
at io.quarkus.deployment.steps.LifecycleEventsBuildStep$startupEvent1144526294.deploy(Unknown Source)
... 11 more
Expected behavior
No classloader problem should happen. The ideal way would be to provide a quarkus-eclipsestore extension so that the user doesn't have to fiddle around or set the class loader themselves.
Additional context
I think the cause of the problem (and maybe a solution) is very similar to https://github.com/quarkusio/quarkus/issues/30741.
Hello, The Quarkus Dev mode is problematic. Beside the class loader handling there is also the hot code replacement. Eclipse Store does a class analysis the first time a class gets persisted, if a class gets modified at runtime those changes will not be detected and may cause unexpected results. In the best case it’s a class cast exception. To handle changes of persisted classes Eclipse Store needs to be reinitialized. When using Eclipse Store you need to disable hot code replacement for all classes that are going to be persisted.
Hi @hg-ms,
I read https://microstream.one/blog/article/quarkus-extension-for-microstream/ and I am wondering if
<dependency>
<groupId>one.microstream</groupId>
<artifactId>microstream-quarkus-extension</artifactId>
<version>08.00.00-MS-GA</version>
</dependency>
can also be used for eclipse-store?
Even if, does this extensions care of
- the bootloader issue
- the disabling of hot code replacement for all classes that are going to be persisted or better: To reinitialize Eclipse Store every time Quarkus Dev is refreshed.
If not, it would be good to provide or enhance the extension to care of that. If this is not possible, then:
- how can I solve this bootloader issue?
- how can I disable the hot code replacement for all classes that are going to be persisted?
- how can I reinitialize Eclipse Store every time Quarkus Dev is refreshed?
The microstream quarkus extension only provides only some basic configuration and storage creation support. It does not address class loading and hot code swapping with the quarkus-dev mode. Regarding the class loader issues I don’t know if Quarkus can be configured to disable hot code swapping for specific class, maybe you can find some help here: https://quarkus.io/guides/class-loading-reference#quarkus-class-loading-configuration-class-loading-config_configuration. As last fallback you may restart the hole application if after you modified a persisted class.
@hg-ms Thanks for your answer - but some points are still unclear:
a) Is microstream-quarkus-extension compatible with eclipse-store or can/should it only be used with the previous microstream-api?
b) Regarding the class loader issues, which class(es) should I exactly disable for hot code exchange in Quarkus Dev mode?
c) And the most important question: Are there plans to provide a quarkus-eclipse-store extension that takes care of such issues, in detail the following:
-
disable hot code swapping for specific eclipse-store class(es) when running in "Quarkus dev mode".
-
reinitialize Eclipse Store every time "Quarkus dev" is refreshed
-
provide Client-GUI in https://quarkus.io/guides/dev-ui (https://docs.microstream.one/manual/storage/rest-interface/client-gui.html can be integrated in DEV UI)
-
seamless integration with Graal VM. The following solutions do not refer to
eclipse-storeand show that graalvm support is currently not fully seamless:- https://github.com/belu/microquark
- https://github.com/microstream-one/example-graalvm-native/tree/master/graalvm-native)
a) Is
microstream-quarkus-extensioncompatible witheclipse-storeor can/should it only be used with the previousmicrostream-api?
The microstream-quarkus-extension can’t be used with Eclipse Store due to the renamed API.
b) Regarding the class loader issues, which class(es) should I exactly disable for hot code exchange in Quarkus Dev mode?
This potentially affects all class that are going to be persisted by Eclipse Store. Most likely this are your data classes of your project, but I’m no Quarkus expert…
c) And the most important question: Are there plans to provide a
quarkus-eclipse-storeextension
There are plans to provide an Eclipse Store extension for Quarkus but I can’t forecast when it will be available and what features will be provided.