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

Use the QuarkusForkJoinWorkerThreadFactory for fork-join pools #20178

Merged
merged 3 commits into from
Oct 8, 2021

Conversation

Sanne
Copy link
Member

@Sanne Sanne commented Sep 15, 2021

An experiment to see if we can better control the Classloaders in the Fork/Join initiated threads.

@stuartwdouglas WDYT of the approach? For dev-mode we'd likely want a slightly different implementation, so to be able to capture all threads when they are started, and then have the ability to swap the CL.

@quarkus-bot quarkus-bot bot added area/core area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins area/jbang Issues related to when using jbang.dev with Quarkus labels Sep 15, 2021
@radcortez
Copy link
Member

Gave it a try with #20067 and it seems to fix the issue. I think it makes sensed to move to this approach.

@radcortez radcortez linked an issue Sep 16, 2021 that may be closed by this pull request
@radcortez
Copy link
Member

@Sanne @stuartwdouglas are we ok to move forward with this?

@Sanne
Copy link
Member Author

Sanne commented Sep 23, 2021

Hi @radcortez - yes sorry I resumed yesterday with this.

I was trying to add some tests, but as I worked on it I realized my new integration tests were pointless, as it affects production mode only so @QuarkusTest isn't affected by the issue.

Do we have any existing pattern / utility to test such things? Any suggestion?

@radcortez
Copy link
Member

Have a look here into how the maven integration tests work: https://github.com/quarkusio/quarkus/blob/main/test-framework/maven/src/main/java/io/quarkus/maven/it/RunAndCheckMojoTestBase.java#L21.

Not exactly what we need, because it runs quarkus:dev, but maybe it can be adjusted (or copied) to run in prod mode. I'm not sure if we have anything else.

I guess that it should be also possible to run the prod jar in pre-integrations-tests and then run tests with failsafe.

@Sanne
Copy link
Member Author

Sanne commented Sep 23, 2021

thanks for the pointers!

@Sanne
Copy link
Member Author

Sanne commented Oct 6, 2021

@radcortez apologies I abandoned this during some emergencies, I'm back on it now. I'll try to finish it soon :)

@quarkus-bot quarkus-bot bot added the area/infra-automation anything related to CI, bots, etc. that are used to automated our infrastructure label Oct 6, 2021
@Sanne Sanne marked this pull request as ready for review October 6, 2021 17:30
@Sanne
Copy link
Member Author

Sanne commented Oct 6, 2021

I've cleaned it up a bit and added integration tests. Should be ready.

I tried to track all places in which we need to set the system property; I followed the example of where java.util.logging.manager is being set to org.jboss.logmanager.LogManager, but this also seems to be set in many tests where it should not really be necessary.

In particular we only need to set java.util.concurrent.ForkJoinPool.common.threadFactory in the Quarkus entrypoints for production mode as that's the only mode affected.

@quarkus-bot
Copy link

quarkus-bot bot commented Oct 6, 2021

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

Failing Jobs - Building 9b8f861

Status Name Step Failures Logs Raw logs
JVM Tests - JDK 11 Build Failures Logs Raw logs
JVM Tests - JDK 11 Windows Build Failures Logs Raw logs
JVM Tests - JDK 17 Build Failures Logs Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ JVM Tests - JDK 11 #

- Failing: extensions/grpc/deployment 
! Skipped: docs integration-tests/devmode integration-tests/grpc-health and 9 more

📦 extensions/grpc/deployment

io.quarkus.grpc.server.devmode.GrpcDevModeTest.testProtoFileChangeReload line 127 - More details - Source on GitHub

java.lang.AssertionError: 

Expecting actual:

⚙️ JVM Tests - JDK 11 Windows #

- Failing: extensions/grpc/deployment 
! Skipped: docs integration-tests/devmode integration-tests/grpc-health and 9 more

📦 extensions/grpc/deployment

io.quarkus.grpc.server.devmode.GrpcDevModeTest.testProtoFileChangeReload line 127 - More details - Source on GitHub

java.lang.AssertionError: 

Expecting actual:

⚙️ JVM Tests - JDK 17 #

- Failing: extensions/grpc/deployment 
! Skipped: docs integration-tests/devmode integration-tests/grpc-health and 9 more

📦 extensions/grpc/deployment

io.quarkus.grpc.server.devmode.GrpcDevModeTest.testProtoFileChangeReload line 127 - More details - Source on GitHub

java.lang.AssertionError: 

Expecting actual:

@radcortez
Copy link
Member

@radcortez apologies I abandoned this during some emergencies, I'm back on it now. I'll try to finish it soon :)

No worries. Thanks!

@radcortez
Copy link
Member

Wondering if the test fails are related, but at first glance it doesn't seem like it.

@stuartwdouglas
Copy link
Member

Failures are unrelated, fixed by #20577

<modelVersion>4.0.0</modelVersion>

<artifactId>production-mode</artifactId>
<name>Quarkus - Integration Tests - Quarkus Production Mode</name>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have heaps of different testing utilities around this already. In particular you can either use:

  • @QuarkusIntegrationTest: This will test whatever artifact was built (jar, docker image, native etc), so you can just use this and make sure the output is always a jar (i.e. disable native)
  • QuarkusProdModeTest: This will build and run a jar using Shrinkwrap in a similar manner to QuarkusUnitTest, but actually testing the production jar.

I think we should use one of our existing mechanisms rather than introducing a new one.

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 have to admit - I thought I tried to use QuarkusProdModeTest earlier and it seemed like some of its tricks would prevent the issue from manifesting.

But your suggestion got me to look better and I probably was confused - preparing now a cleanup which switches to use QuarkusProdModeTest.

I was also attempting to have this test in the main integration tests, but I'm hitting a series of accidental problems having to coexist with all other tests, so I'd prefer to keep it in this module for now.

@Sanne
Copy link
Member Author

Sanne commented Oct 7, 2021

Pushed a cleaned up version following @stuartwdouglas 's suggestions.

Thanks!

@Sanne
Copy link
Member Author

Sanne commented Oct 7, 2021

pushed again, CI highlighted a problem.

This is where core functionality is usually tested, and removes the need
for another maven module.
@stuartwdouglas
Copy link
Member

@Sanne I have pushed a commit on top of this that moves the test to core/test-extension, which is where we usually test core functionality. As much as possible I want to avoid adding new modules unless we really need them. Let me know if this looks ok to you.

@stuartwdouglas stuartwdouglas dismissed their stale review October 7, 2021 23:35

things changed

@quarkus-bot
Copy link

quarkus-bot bot commented Oct 8, 2021

Failing Jobs - Building 1ade67f

Status Name Step Failures Logs Raw logs
JVM Tests - JDK 11 Build Failures Logs Raw logs
JVM Tests - JDK 11 Windows Build Failures Logs Raw logs
JVM Tests - JDK 17 Build ⚠️ Check → Logs Raw logs

Full information is available in the Build summary check run.

⚠️ Errors occurred while downloading the build reports. This report is incomplete.

Failures

⚙️ JVM Tests - JDK 11 #

- Failing: integration-tests/oidc 

📦 integration-tests/oidc

io.quarkus.it.keycloak.WebsocketOidcTestCase.websocketTest line 49 - More details - Source on GitHub

org.opentest4j.AssertionFailedError: expected: <hello [email protected]> but was: <null>
	at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
	at org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)

⚙️ JVM Tests - JDK 11 Windows #

- Failing: devtools/cli 

📦 devtools/cli

io.quarkus.cli.CliProjectMavenTest.testCreateAppDefaults line 61 - More details - Source on GitHub

org.opentest4j.AssertionFailedError: 
Expected OK return code. Result:
result: {

io.quarkus.cli.CliProjectMavenTest.testCreateCliDefaults line 38 - More details - Source on GitHub

org.opentest4j.AssertionFailedError: expected: <false> but was: <true>
	at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
	at org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:40)

@Sanne
Copy link
Member Author

Sanne commented Oct 8, 2021

@Sanne I have pushed a commit on top of this that moves the test to core/test-extension, which is where we usually test core functionality. As much as possible I want to avoid adding new modules unless we really need them. Let me know if this looks ok to you.

Sure, great thanks! I didn't know where to put it, and thought that core/test-extension was something different.

And nice to see the CLI based test :)

@Sanne
Copy link
Member Author

Sanne commented Oct 8, 2021

@radcortez looks like we're ready to merge; is there any open issue this should be linked to?

@radcortez
Copy link
Member

@radcortez looks like we're ready to merge; is there any open issue this should be linked to?

I'm not aware of any other options issues. Please go ahead. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/core area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins area/infra-automation anything related to CI, bots, etc. that are used to automated our infrastructure area/jbang Issues related to when using jbang.dev with Quarkus
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Config property not found when in ForkJoin common Pool thread
3 participants