-
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
Use the QuarkusForkJoinWorkerThreadFactory for fork-join pools #20178
Conversation
Gave it a try with #20067 and it seems to fix the issue. I think it makes sensed to move to this approach. |
...p/runner/src/main/java/io/quarkus/bootstrap/forkjoin/QuarkusForkJoinWorkerThreadFactory.java
Show resolved
Hide resolved
@Sanne @stuartwdouglas are we ok to move forward with this? |
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? |
Have a look here into how the Not exactly what we need, because it runs I guess that it should be also possible to run the prod jar in |
thanks for the pointers! |
@radcortez apologies I abandoned this during some emergencies, I'm back on it now. I'll try to finish it soon :) |
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 In particular we only need to set |
This workflow status is outdated as a new workflow run has been triggered. Failing Jobs - Building 9b8f861
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✖
⚙️ JVM Tests - JDK 11 Windows #- Failing: extensions/grpc/deployment
! Skipped: docs integration-tests/devmode integration-tests/grpc-health and 9 more 📦 extensions/grpc/deployment✖
⚙️ JVM Tests - JDK 17 #- Failing: extensions/grpc/deployment
! Skipped: docs integration-tests/devmode integration-tests/grpc-health and 9 more 📦 extensions/grpc/deployment✖
|
No worries. Thanks! |
Wondering if the test fails are related, but at first glance it doesn't seem like it. |
Failures are unrelated, fixed by #20577 |
<modelVersion>4.0.0</modelVersion> | ||
|
||
<artifactId>production-mode</artifactId> | ||
<name>Quarkus - Integration Tests - Quarkus Production Mode</name> |
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.
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.
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 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.
core/deployment/src/main/java/io/quarkus/deployment/dev/QuarkusDevModeLauncher.java
Outdated
Show resolved
Hide resolved
Pushed a cleaned up version following @stuartwdouglas 's suggestions. Thanks! |
…oader in the Fork/Join common pool
pushed again, CI highlighted a problem. |
This is where core functionality is usually tested, and removes the need for another maven module.
@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. |
Failing Jobs - Building 1ade67f
Full information is available in the Build summary check run. Failures⚙️ JVM Tests - JDK 11 #- Failing: integration-tests/oidc
📦 integration-tests/oidc✖
⚙️ JVM Tests - JDK 11 Windows #- Failing: devtools/cli
📦 devtools/cli✖
✖
|
Sure, great thanks! I didn't know where to put it, and thought that And nice to see the CLI based test :) |
@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! |
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.