Closed wjglerum closed 7 months ago
geoand
commented
12 months ago At least now I am not the only person capable of writing somewhat acceptable code because quarkus/mutiny really feels like another programming language, if you only know "classic imperative java".
That is all fine and well, but you can use Quarkus in an imperative way, and it's probably the best approach for most use cases.
Froidoh
commented
12 months ago At least now I am not the only person capable of writing somewhat acceptable code because quarkus/mutiny really feels like another programming language, if you only know "classic imperative java".
That is all fine and well, but you can use Quarkus in an imperative way, and it's probably the best approach for most use cases.
I would argue that this advice should be way more prominent on the website. If you search for quarkus you mostly find the mutiny/vert.x and non-blocking examples that distinguish quarkus from other frameworks in java-land.
Also one additional note: What really made a big impact in the decision finding was a new requirement to use redis. A colleague of mine read up the docs, implemented it and it doesn't work if there are more than one hosts specified.
Took them a few minutes to get it working in Spring. Granted, they are way more familiar with Spring.
geoand
commented
12 months ago I would argue that this advice should be way more prominent on the website. If you search for quarkus you mostly find the mutiny/vert.x and non-blocking examples that distinguish quarkus from other frameworks in java-land.
Although we have been saying from day 1 that Quarkus can be used in both imperative and reactive mode (and the styles can even be mixed in the same application), the fact that you have not got that impression means we certainly need to do much better.
Also one additional note: What really made a big impact in the decision finding was a new requirement to use redis. A colleague of mine read up the docs, implemented it and it doesn't work if there are more than one hosts specified.
I would need to know more details about this to give a proper answer
Sanne
commented
7 months ago Hi all, there's good feedback in here in the various comments which probably deserves their own issues and/or some further attention, however the main problem being described of "This worked in Quarkus 2 and now no longer works" is not a bug: it was illegal and problematic also in Quarkus 2, we simply have better validations nowadays.
So I think we should close this as it's not particularly actionable.. sorry for all confusion.
Allow me to give some advise: use Hibernate Reactive exclusively if you have a "pure" reactive application.
Attempting to switch threads back and forth from blocking to reactive will only result in significant efficiency waste, making the use of Hibernate Reactive pointless. If you're on a regular executor (not the vertx/netty threads) you're better off to use the "regular" Hibernate ORM within a blocking thread, and remember there's nothing inherently bad about it as we optimised the regular ORM a lot as well: if you find inefficiencies in it, let us know!
On the other hand if your entire flow of operations is running on the vertx(netty) IO threads, then (and only then) you can really benefit from Hibernate Reactive: but remember the benefit of it really stems from the fact that you're NOT switching threads and executors. Such switches are the operation to avoid to achieve an high performance, highly efficient system, so attempting to shoehorn Hibernate Reactive operations from within a blocking thread just doesn't make much sense.
HTH
Describe the bug
In Quarkus 2 it's possible to combine blocking calls when writing to the database with Hibernate Reactive with Panache. It looks like this is not possible anymore in Quarkus 3.
Take the following use case:
.runSubscriptionOn(Infrastructure.getDefaultWorkerPool()), see https://smallrye.io/smallrye-mutiny/2.1.0/guides/imperative-to-reactive/#running-blocking-code-on-subscriptionThis all worked fine on Quarkus 2 (the latest I tried was
2.16.6.Final), but doesn't work on Quarkus 3 (3.0.0.CR2)Expected behavior
I would expect that we can do some blocking work during a transaction when using Hibernate Reactive, especially when we delegate that blocking work to a worker thread and switch back to an event loop thread when we persist the entity with Hibernate Reactive.
Actual behavior
The scheduled method fails with the following exception:
How to Reproduce?
Attached reactive.zip is a simple project that reproduces the error.
./mvnw quarkus:dev./mvnw quarkus:dev -Dorg.hibernate.reactive.common.InternalStateAssertions.ENFORCE=falseOutput of
uname -aorverOutput of
java -versionGraalVM version (if different from Java)
No response
Quarkus version or git rev
Build tool (ie. output of
mvnw --versionorgradlew --version)Additional information
Looks related to https://github.com/quarkusio/quarkus/issues/32533