Skip to content
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

Merged
merged 4 commits into from
May 5, 2021
Merged

Conversation

Sanne
Copy link
Member

@Sanne Sanne commented Apr 30, 2021

Fixes #16860
Fixes #16450
Fixes #16463
Fixes #16712

@Sanne Sanne added area/persistence OBSOLETE, DO NOT USE triage/backport? area/hibernate-orm Hibernate ORM area/hibernate-reactive Hibernate Reactive labels Apr 30, 2021
@quarkus-bot quarkus-bot bot added the area/dependencies Pull requests that update a dependency file label Apr 30, 2021
@Sanne Sanne requested a review from yrodiere April 30, 2021 09:41
@yrodiere yrodiere added the triage/waiting-for-ci Ready to merge when CI successfully finishes label Apr 30, 2021
@quarkus-bot
Copy link

quarkus-bot bot commented Apr 30, 2021

This workflow status is outdated as a new workflow run has been triggered.

Failing Jobs - Building c3dd446

Status Name Step Test failures Logs Raw logs
JVM Tests - JDK 11 Build Test failures Logs Raw logs
JVM Tests - JDK 15 Build Test failures Logs Raw logs
Maven Tests - JDK 11 Build Test failures Logs Raw logs
Native Tests - Data5 Build Test failures Logs Raw logs

Full information is available in the Build summary check run.

Test Failures

⚙️ JVM Tests - JDK 11 #

📦 integration-tests/hibernate-reactive-panache

io.quarkus.it.panache.reactive.PanacheFunctionalityTest.testCompositeKey line 118 - More details - Source on GitHub

io.quarkus.it.panache.reactive.PanacheFunctionalityTest.testPanacheFunctionality line 42 - More details - Source on GitHub

📦 integration-tests/hibernate-reactive-postgresql

io.quarkus.it.hibernate.reactive.postgresql.HibernateReactiveTest.reactivePersist line 46 - More details - Source on GitHub

io.quarkus.it.hibernate.reactive.postgresql.HibernateReactiveTest.reactiveRemoveTransientEntity line 54 - More details - Source on GitHub

io.quarkus.it.hibernate.reactive.postgresql.HibernateReactiveTest.reactiveFindMutiny line 38 - More details - Source on GitHub


⚙️ JVM Tests - JDK 15 #

📦 integration-tests/hibernate-reactive-panache

io.quarkus.it.panache.reactive.PanacheFunctionalityTest.testPanacheFunctionality line 45 - More details - Source on GitHub

📦 integration-tests/hibernate-reactive-postgresql

io.quarkus.it.hibernate.reactive.postgresql.HibernateReactiveTest.reactivePersist line 46 - More details - Source on GitHub

io.quarkus.it.hibernate.reactive.postgresql.HibernateReactiveTest.reactiveRemoveTransientEntity line 54 - More details - Source on GitHub

io.quarkus.it.hibernate.reactive.postgresql.HibernateReactiveTest.reactiveFindMutiny line 38 - More details - Source on GitHub


⚙️ Maven Tests - JDK 11 #

📦 integration-tests/maven

io.quarkus.maven.it.DevMojoIT.testThatNewResourcesAreServed line 841 - More details - Source on GitHub


⚙️ Native Tests - Data5 #

📦 integration-tests/hibernate-reactive-postgresql

io.quarkus.it.hibernate.reactive.postgresql.HibernateReactiveAlternativeInGraalIT.reactiveRemoveManagedEntity - More details - Source on GitHub

io.quarkus.it.hibernate.reactive.postgresql.HibernateReactiveAlternativeInGraalIT.reactiveUpdate - More details - Source on GitHub

io.quarkus.it.hibernate.reactive.postgresql.HibernateReactiveAlternativeInGraalIT.reactiveRemoveTransientEntity - More details - Source on GitHub

@yrodiere
Copy link
Member

@Sanne @DavideD @gavinking Plenty of failing tests for Hibernate Reactive after the upgrade... I see timeouts in particular. Could this be related to the session.close() changes?

@Sanne
Copy link
Member Author

Sanne commented Apr 30, 2021

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

@DavideD
Copy link
Contributor

DavideD commented Apr 30, 2021

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.

@DavideD
Copy link
Contributor

DavideD commented Apr 30, 2021

Could it be related to the upgrade to ORM 5.5?
Other changes are the upgrade to Mutiny 0.16 and a bug fix to one-to-one associations

@Sanne
Copy link
Member Author

Sanne commented Apr 30, 2021

Could it be related to the upgrade to ORM 5.5?

No we didn't upgrade to 5.5 yet

@DavideD
Copy link
Contributor

DavideD commented Apr 30, 2021

The last suspicious thing I can think of is this blocking call: hibernate/hibernate-reactive@f0d59b2

What's the error anyway?

@yrodiere
Copy link
Member

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

@Sanne
Copy link
Member Author

Sanne commented Apr 30, 2021

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 close() implementation was:

    public void close() {
		delegate.close();
    }

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:

	public Uni<Void> close() {
		return uni( delegate::reactiveClose );
	}

The problem is amplified in the Quarkus code as the CDI dispose method is implemented as:

public void disposeStageSession(@Disposes Stage.Session reactiveSession) {
if (reactiveSession != null) {
reactiveSession.close();
}
}
public void disposeMutinySession(@Disposes Mutiny.Session reactiveSession) {
if (reactiveSession != null) {
reactiveSession.close();
}
}

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.

@Sanne
Copy link
Member Author

Sanne commented May 4, 2021

Pushed something for CI to test - I'm having trouble testing with DB2 locally

@quarkus-bot
Copy link

quarkus-bot bot commented May 4, 2021

Failing Jobs - Building 485d1f3

Status Name Step Test failures Logs Raw logs
JVM Tests - JDK 11 Build Test failures Logs Raw logs
JVM Tests - JDK 11 Windows Build ⚠️ Check → Logs Raw logs
JVM Tests - JDK 15 Build Test failures Logs Raw logs
Maven Tests - JDK 11 Build Test failures Logs Raw logs
MicroProfile TCKs Tests Verify Test failures Logs Raw logs

Full information is available in the Build summary check run.

Test Failures

⚙️ JVM Tests - JDK 11 #

📦 core/test-extension/deployment

io.quarkus.extest.ConfiguredBeanTest.testConfigDefaultValuesSourceOrdinal line 346 - More details - Source on GitHub


⚙️ JVM Tests - JDK 15 #

📦 core/test-extension/deployment

io.quarkus.extest.ConfiguredBeanTest.testConfigDefaultValuesSourceOrdinal line 346 - More details - Source on GitHub


⚙️ Maven Tests - JDK 11 #

📦 integration-tests/maven

io.quarkus.maven.it.DevMojoIT.testThatNewResourcesAreServed line 841 - More details - Source on GitHub


⚙️ MicroProfile TCKs Tests #

📦 tcks/microprofile-config

org.eclipse.microprofile.config.tck.ConfigPropertiesTest.testConfigPropertiesDefaultOnBean line 172 - More details - Source on GitHub

org.eclipse.microprofile.config.tck.ConfigPropertiesTest.testConfigPropertiesNoPrefixOnBean line 149 - More details - Source on GitHub

org.eclipse.microprofile.config.tck.ConfigPropertiesTest.testConfigPropertiesNoPrefixOnBeanThenSupplyPrefix line 156 - More details - Source on GitHub

org.eclipse.microprofile.config.tck.ConfigPropertiesTest.testConfigPropertiesPlainInjection line 106 - More details - Source on GitHub

org.eclipse.microprofile.config.tck.ConfigPropertiesTest.testConfigPropertiesWithPrefix line 115 - More details - Source on GitHub

org.eclipse.microprofile.config.tck.ConfigPropertiesTest.testConfigPropertiesWithoutPrefix line 132 - More details - Source on GitHub

org.eclipse.microprofile.config.tck.ConfigPropertiesTest.testNoConfigPropertiesAnnotationInjection line 165 - More details - Source on GitHub

@Sanne
Copy link
Member Author

Sanne commented May 5, 2021

Soo still some failing tests but they seem unrelated to my changes.

WDYT @yrodiere @gsmet ?
We need this, lots of progress is being stalled, so while I don't like CI status I'm inclined to merge

@yrodiere yrodiere self-requested a review May 5, 2021 06:28
Copy link
Member

@yrodiere yrodiere left a 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!
Copy link
Member

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:

Suggested change
//We're ignoring the returned CompletionStage!
//We must not ignore the returned CompletionStage!

Copy link
Member Author

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!
Copy link
Member

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:

Suggested change
//We're ignoring the returned CompletionStage!
//We must not ignore the returned CompletionStage!

@Sanne
Copy link
Member Author

Sanne commented May 5, 2021

LGTM apart from a comment that seems misleading. In any case, +1 to merge as the failures seem completely unrelated.

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!

@Sanne Sanne merged commit 1d994fe into quarkusio:main May 5, 2021
@quarkus-bot quarkus-bot bot added this to the 2.0 - main milestone May 5, 2021
@Sanne Sanne deleted the BasicProxies branch May 5, 2021 07:39
@quarkus-bot quarkus-bot bot removed the triage/waiting-for-ci Ready to merge when CI successfully finishes label May 5, 2021
@Sanne
Copy link
Member Author

Sanne commented May 5, 2021

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

@gavinking
Copy link

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?

@Sanne
Copy link
Member Author

Sanne commented May 5, 2021

@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

@gavinking
Copy link

OK. Let me know if you change your mind. I really don't think it would be a big deal to do a release.

@DavideD
Copy link
Contributor

DavideD commented May 5, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment