Hibernate RX no longer works as it did for a Picocli application #27339
Comments
|
/cc @ebullient |
|
I've tried |
gsmet
added
triage/needs-triage
area/hibernate-reactive
|
/cc @DavideD, @Sanne, @ebullient, @gavinking |
|
I've no idea what the sub-context error is about, but @cescoffier should know. I'll note that you don't need |
|
Hibernate Reactive requires to be invoked from a Vert.x thread. This is not the case in your case (you are on the main thread). You can inject the Vert.x instance and run your code from a Vert.x context; however, it seems that you are awaiting for the result, which would block the event loop (and so break the whole model) |
|
I had tried |
|
Maybe this should be or transform into a feature request instead if there isn't a good way to await reactive tasks from a CLI application. I filed a bug because this had previously worked like a charm during previous Quarkus versions. From my perspective it isn't outlandish to want to write async command line tools. I'm all ears if there are any small workarounds to try to continue using the reactive model in this application until (hopefully + eventually) support arrives. Since I'm using the reactive model for DB, API, and file system IO it would be a costly refactor to change everything to use an imperative model so I'm holding off on that option. I do appreciate everyone's time digging into this so far. Thank you! |
|
I was able to use the following workaround to obtain a session from the session factory. public <T> Uni<T> wrapWithContext(Function<Mutiny.Session, Uni<T>> work) {
var context = ((ContextInternal)vertx.getOrCreateContext().getDelegate()).duplicate();
VertxContextSafetyToggle.setContextSafe(context, true);
return Uni.createFrom().<Uni<T>>emitter(emitter -> {
context.runOnContext(ignored -> {
try {
Uni<T> result = sessionFactory.withTransaction(work);
emitter.complete(result);
} catch (Throwable e) {
emitter.fail(e);
}
});
}).flatMap(uni -> uni);
} |
|
Frankly, for a CLI application, use Hibernate ORM. I see no point in paying the price of the complexity you will end up with the reactive flavor. |
|
Personally I think there is a benefit to shared code and knowledge gained from writing reactive Quarkus services (like REST APIs and Kafka consumers where reactive is more naturally supported and promoted). Whether it is worth officially supporting (maybe a Uni-based Picocli Command or simply having documented ways to safely integrate reactive pipelines) or not is up to you maintainers. As an application author it would be nice to have the option when building a new CLI to choose to use the reactive model without depending on internals or low level details likely to break in a future release. |
|
I think that both of the above points make sense. On one hand, it doesn't make a tremendous amount of sense to use a reactive stack in a CLI application, on the other hand this should not be a limiting factor IMO. |
|
The Duplicated Context doc we now have should make running HR in a |
Describe the bug
Previously I had built a simple CLI application for initializing a standard set of records for testing in an environment. Records were initialized through SQL queries. When the first version was built early this year I was using Quarkus 2.7 and was able to build everything out using the Hiberate RX and Picocli extensions. However now that I've tried upgraded to the latest Quarkus version a few times over the last few months (2.9 then 2.11) I now encounter a run-time error that stops this once running code in its tracks. My command for initializing a SQL dataset is no longer able to run it's stateful transaction without encountering an error about not having a safe Vert.x sub-context.
Expected behavior
Queries should run and complete as they did before.
Actual behavior
This exception is throw as soon as the
sessionFactory.withTransactionmethod is invoked:How to Reproduce?
I've tried to strip things down to a simple conceptual example:
Primary Maven Dependencies
Picocli Command Class
Output of
uname -aorverLinux user 5.15.0-46-generic #49-Ubuntu SMP Thu Aug 4 18:03:25 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Output of
java -versionopenjdk version "17.0.4" 2022-07-19 LTS OpenJDK Runtime Environment Corretto-17.0.4.8.1 (build 17.0.4+8-LTS) OpenJDK 64-Bit Server VM Corretto-17.0.4.8.1 (build 17.0.4+8-LTS, mixed mode, sharing)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.11.2
Build tool (ie. output of
mvnw --versionorgradlew --version)Apache Maven 3.8.5
Additional information
No response
The text was updated successfully, but these errors were encountered: