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

Vert.x TCCL fixes #19487

Merged
merged 1 commit into from
Aug 20, 2021
Merged

Vert.x TCCL fixes #19487

merged 1 commit into from
Aug 20, 2021

Conversation

stuartwdouglas
Copy link
Member

No description provided.

if (launchMode == LaunchMode.DEVELOPMENT) {
devModeThreads.add(thread);
}
return VertxThreadFactory.super.newVertxThread(target, name, worker, maxExecTime, maxExecTimeUnit);
Copy link
Member

Choose a reason for hiding this comment

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

I suppose you meant to return the existing thread instance?

Copy link
Member

Choose a reason for hiding this comment

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

I mean, rather than invoking the factory once more.

EnhancedQueueExecutor executor = (EnhancedQueueExecutor) result;
final Thread[] runningThreads = executor.getRunningThreads();
for (Thread t : runningThreads) {
for (var t : devModeThreads) {
Copy link
Member

Choose a reason for hiding this comment

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

Awesome 👍

@@ -383,7 +383,7 @@ private RunTimeConfigurationGenerator() {
cc.getFieldCreator(C_BUILD_TIME_CONFIG_SOURCE)
.setModifiers(Opcodes.ACC_PUBLIC | Opcodes.ACC_STATIC | Opcodes.ACC_FINAL);
final ResultHandle buildTimeConfigSource = clinit.newInstance(PCS_NEW, buildTimeValues,
clinit.load("Build time config"), clinit.load(100));
clinit.load("Build time config"), clinit.load(Integer.MAX_VALUE));
Copy link
Member

Choose a reason for hiding this comment

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

How is this related?

@stuartwdouglas stuartwdouglas force-pushed the reset-tccl branch 2 times, most recently from d3052a3 to 4a87bb2 Compare August 18, 2021 20:51
@famod
Copy link
Member

famod commented Aug 18, 2021

FTR, I confirm that this is fixing that nasty problem we were fighting with the last few days: https://quarkusio.zulipchat.com/#narrow/stream/187038-dev/topic/main.3A.20NPE.20in.20SR.20Config.20ClassPathUtils/near/249911993

Thanks @stuartwdouglas, master of threads, contexts and loaders! 😁

@Sanne
Copy link
Member

Sanne commented Aug 18, 2021

there's a potential race condition between expansion of the threadpool and the context being swapped: not a blocker for the current excellent PR, but we should follow up on that.

Also considering some machines might want to start lots of threads, I'd replace the "copy on write set" with a regular set , as we get rid of the race with a lock.

@stuartwdouglas stuartwdouglas force-pushed the reset-tccl branch 2 times, most recently from 14a2def to e381f0f Compare August 18, 2021 21:50
@stuartwdouglas
Copy link
Member Author

@Sanne race should be gone now, and it is also a lot more careful not to capture the original TCCL and cause a leak in dev mode.

@quarkus-bot
Copy link

quarkus-bot bot commented Aug 19, 2021

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

Failing Jobs - Building 8ed92ed

Status Name Step Test failures Logs Raw logs
✔️ JVM Tests - JDK 11
JVM Tests - JDK 11 Windows Build ⚠️ Check → Logs Raw logs
✔️ JVM Tests - JDK 16

@@ -230,6 +176,10 @@ public void handle(AsyncResult<Void> event) {
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
synchronized (devModeThreads) {
Copy link
Member

Choose a reason for hiding this comment

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

Hello Stuart, is there a chance that the threads and classloader will leak if the previous try block throws an exception? In other words, should we use a finally block here to clear the collection and the classloader?

Copy link
Member Author

Choose a reason for hiding this comment

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

In theory this could happen, I will change it.

@quarkus-bot
Copy link

quarkus-bot bot commented Aug 19, 2021

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

Failing Jobs - Building e761880

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

Full information is available in the Build summary check run.

Test Failures

⚙️ MicroProfile TCKs Tests #

📦 tcks/microprofile-fault-tolerance

org.eclipse.microprofile.fault.tolerance.tck.TimeoutUninterruptableTest.testTimeoutAsyncBulkhead line 190 - More details - Source on GitHub

java.lang.AssertionError: Unexpected exception thrown from Future
	at org.testng.Assert.fail(Assert.java:85)
	at org.eclipse.microprofile.fault.tolerance.tck.util.Exceptions.expect(Exceptions.java:98)
	at org.eclipse.microprofile.fault.tolerance.tck.TimeoutUninterruptableTest.testTimeoutAsyncBulkhead(TimeoutUninterruptableTest.java:190)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at io.quarkus.arquillian.QuarkusProtocol$QuarkusMethodExecutor$1.invoke(QuarkusProtocol.java:87)
	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:57)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base...

@@ -253,9 +204,34 @@ public static Vertx initialize(VertxConfiguration conf, VertxOptionsCustomizer c

Vertx vertx;

Optional<ClassLoader> nonDevModeTccl;
Copy link
Member

Choose a reason for hiding this comment

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

This whole block looks very similar to createThreadFactory(), no?

IMO, the complexity warrants a single method that can be used in both cases, but YMMV!

@quarkus-bot
Copy link

quarkus-bot bot commented Aug 20, 2021

Failing Jobs - Building 8d4a650

Status Name Step Test failures Logs Raw logs
Gradle Tests - JDK 11 Windows Build Test failures Logs Raw logs

Full information is available in the Build summary check run.

Test Failures

⚙️ Gradle Tests - JDK 11 Windows #

📦 integration-tests/gradle

io.quarkus.gradle.devmode.QuarkusDevDependencyDevModeTest.main line 14 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference, java.util.concurrent.atomic.AtomicReferencejava.lang.String, java.lang.Stringboolean was not fulfilled within 1 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:908)
	at io.quarkus.test.devmode.util.DevModeTestUtils.getHttpResponse(DevModeTestUtils.java:130)
	at io.quarkus.gradle.devmode.QuarkusDevGradleTestBase.getHttpResponse(QuarkusDevGradleTestBase.java:126)
	at io.quarkus.gradle.devmode.QuarkusDevGradleTestBase.getHttpRes...

Copy link
Member

@famod famod left a comment

Choose a reason for hiding this comment

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

LGTM and it still fixes the problem I was seeing. 🤓

@famod
Copy link
Member

famod commented Aug 20, 2021

I briefly tested a few other things with my current app (e.g. dev mode reload) and it's all looking good so far.

@famod famod merged commit 0cd5c9f into quarkusio:main Aug 20, 2021
@quarkus-bot quarkus-bot bot added this to the 2.3 - main milestone Aug 20, 2021
@gsmet gsmet modified the milestones: 2.3 - main, 2.2.0.Final Aug 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants