-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Hibernate ORM, Hibernate Reactive #16923
Conversation
This workflow status is outdated as a new workflow run has been triggered. Failing Jobs - Building c3dd446
Full information is available in the Build summary check run. Test Failures⚙️ JVM Tests - JDK 11 #📦 integration-tests/hibernate-reactive-panache✖ ✖ 📦 integration-tests/hibernate-reactive-postgresql✖ ✖ ✖ ⚙️ JVM Tests - JDK 15 #📦 integration-tests/hibernate-reactive-panache✖ 📦 integration-tests/hibernate-reactive-postgresql✖ ✖ ✖ ⚙️ Maven Tests - JDK 11 #📦 integration-tests/maven✖ ⚙️ Native Tests - Data5 #📦 integration-tests/hibernate-reactive-postgresql✖ ✖ ✖ |
@Sanne @DavideD @gavinking Plenty of failing tests for Hibernate Reactive after the upgrade... I see timeouts in particular. Could this be related to the |
I'm sorry, I don't know. I guess it could relate, but things were not being closed correctly even before the patch so while it's certainly a suspect, it doesn't feel too likely either |
Weird, wasn't it tested before? @yrodiere Possible, but it would surprise me a bit. We didn't have a reactive close in the previous version of Hibernate Reactive (even if the connection underneath was reactive) so connections were already closed the wrong way even before the update. |
Could it be related to the upgrade to ORM 5.5? |
No we didn't upgrade to 5.5 yet |
The last suspicious thing I can think of is this blocking call: hibernate/hibernate-reactive@f0d59b2 What's the error anyway? |
I don't know more than what appears on the report; apparently the integration test times out. So I think something hangs forever in Reactive. May be a problem in tests, though they used to pass and they didn't change... See https://github.com/quarkusio/quarkus/runs/2475746313 |
Ok I think I have a more concrete idea. With the Mutiny API wrappers, an async method without any subscription is never invoked - this is different than a Future, in which case the lack of a subscription will defer the operation but it will still be run eventually. So the previous version of Hibernate Reactive's
Which was wrong as Vert.x 4 made the "close" asynchronous, but at least it would be triggered eventually. But now that in the Mutiny version it was patched as:
The problem is amplified in the Quarkus code as the CDI dispose method is implemented as: Lines 35 to 45 in 09d03ab
N.B. the lack of subcriptions (not sure how to fix this in a CDI friendly way && without blocking) So now the end effect is that since it's a Mutiny based wrapper and there is actually no subscription, it's never triggered and we run out of connections. |
Pushed something for CI to test - I'm having trouble testing with DB2 locally |
Failing Jobs - Building 485d1f3
Full information is available in the Build summary check run. Test Failures⚙️ JVM Tests - JDK 11 #📦 core/test-extension/deployment✖ ⚙️ JVM Tests - JDK 15 #📦 core/test-extension/deployment✖ ⚙️ Maven Tests - JDK 11 #📦 integration-tests/maven✖ ⚙️ MicroProfile TCKs Tests #📦 tcks/microprofile-config✖ ✖ ✖ ✖ ✖ ✖ ✖ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM apart from a comment that seems misleading. In any case, +1 to merge as the failures seem completely unrelated.
@@ -34,13 +34,24 @@ | |||
|
|||
public void disposeStageSession(@Disposes Stage.Session reactiveSession) { | |||
if (reactiveSession != null) { | |||
reactiveSession.close(); | |||
//We're ignoring the returned CompletionStage! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the change but I think the comment should be:
//We're ignoring the returned CompletionStage! | |
//We must not ignore the returned CompletionStage! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually referring to the fact that the disposeStageSession
method itself (the one we're changing here) is returning void - while it should chain the event back to a reactive chain. That's sadly not possible with CDI at the moment.
So "must not ignore" would IMO be confusing as we are actually ignoring it here?
} | ||
} | ||
|
||
public void disposeMutinySession(@Disposes Mutiny.Session reactiveSession) { | ||
if (reactiveSession != null) { | ||
reactiveSession.close(); | ||
//We're ignoring the returned CompletionStage! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the change but I think the comment should be:
//We're ignoring the returned CompletionStage! | |
//We must not ignore the returned CompletionStage! |
right - and I've checked now that the other failures are indeed reproducible w/o my patch. Stuart also seems to have just fixed one of them in #16986 I'll merge - thanks! |
Sadly, I've decided to remove the "backport" label: Let's try to backport these fixes only if there's strong need - the problem is that while I'm comfortable with the changes in ORM, there is a high coupling requiring the HR upgrade as well - which now requires Vertx4 in this release. Backporting would need an alternative stream of HR artifacts. cc/ @gavinking @DavideD |
Off the top of my head I don't think it would be that hard to do a dedicated HR release against the pre-vert.x 4 version. But i'm having a hard time gauging the priority. How important is this? |
@gavinking I think we can live just fine without one for now, I only mentioned it so you're aware that we might need one in the future. We should also learn about such constraints, clearly I got the release sequence puzzle wrong this time - sorry |
OK. Let me know if you change your mind. I really don't think it would be a big deal to do a release. |
I didn't check the whole consversation, but releasing different versions of
hibernate reactive is pretty straight forward. For different versions of
vertx (3
9 and 4.0) we need to maintain different branches though.
…On Wed, 5 May 2021, 10:42 Gavin King, ***@***.***> wrote:
OK. Let me know if you change your mind. I really don't think it would be
a big deal to do a release.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#16923 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEIQ5PTULDJ335BFUM3IHLTMEHJXANCNFSM43326W3A>
.
|
Fixes #16860
Fixes #16450
Fixes #16463
Fixes #16712