Bootloader issues with Quarkus about store HOT 5 OPEN

@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:

1. disable hot code swapping for specific eclipse-store class(es) when running in "Quarkus dev mode".

2. reinitialize Eclipse Store every time "Quarkus dev" is refreshed

3. 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)

4. seamless integration with Graal VM. The following solutions do not refer to eclipse-store and 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)

from store.

a) Is microstream-quarkus-extension compatible with eclipse-store or can/should it only be used with the previous microstream-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-store extension

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.

from store.

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.

from store.

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?

from store.

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.

from store.