[WIP] tck multithread failures #673

olamy · 2025-02-04T11:09:52Z

investigate junit5 multi thread build failure Servlet TCK with Jetty
more thread safe collections
not sure about those but some thread safe fields

Short description of what this resolves:

Changes proposed in this pull request:

Fixes #

rhusar · 2025-02-07T17:21:17Z

@olamy Can you link the reproducer?

olamy · 2025-02-08T09:28:03Z

@olamy Can you link the reproducer?

sure have a look here https://github.com/jetty-project/servlet-tck-run/ use branch jetty-12-ee11-parallel-test

mvn clean verify you may have a lot of download of snapshots, you will have to change the arquillian-core version in the pom. (it's using the version of this PR for testing purpose)

with the current content content of this PR I managed to reduced by a lot failure number because of this change https://github.com/arquillian/arquillian-core/pull/673/files#diff-5c09558098ba87d126edb03750d0b116404b1680a7821a0d206789d58f768d32R12

I still have some errors such

java.lang.NullPointerException: deploymentScenario cannot be null
	at java.base/java.util.Objects.requireNonNull(Objects.java:235)
	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.lookup(ContainerEventController.java:147)
	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:133)
	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:117)

note I have added the check here https://github.com/arquillian/arquillian-core/pull/673/files#diff-94ece6fcd6683e6db69d1647fcf29bf2091d8f73deb8dd991848755b646e94d7R147 to track this.

ETA is some random state failures with each builds.

Update on reproducer:

get branch jetty-12-1-ee11 from https://github.com/jetty-project/servlet-tck-run.git
You will need to build locally branch jetty-12.1-fix-deployer from https://github.com/arquillian/arquillian-container-jetty

eventually update the property <arquillian.core.version>1.9.5.Final-SNAPSHOT</arquillian.core.version><arquillian.core.version>1.9.5.Final-SNAPSHOT</arquillian.core.version> from the sevlet-tck-run project

mvn clean verify -Djunit.jupiter.execution.parallel.enabled=true

jamezp

Overall I think this is a good idea to make Arquillian more thread-safe. However, I do think it will be quite a task to do so.

jamezp · 2025-04-16T23:38:16Z

core/impl-base/src/main/java/org/jboss/arquillian/core/impl/EventContextImpl.java

-        this.interceptors = interceptors == null ? new ArrayList<ObserverMethod>() : interceptors;
-        this.observers = observers == null ? new ArrayList<ObserverMethod>() : observers;
+        if(interceptors!=null) {
+            this.interceptors.addAll(interceptors);
+        }
+        if(observers!=null) {
+            this.observers.addAll(observers);
+        }


This should use the constructor instead of addAll() to avoid lock.

jamezp · 2025-04-16T23:40:01Z

test/impl-base/src/main/java/org/jboss/arquillian/test/impl/TestContextHandler.java

    // Since there can be multiple AfterTestLifecycleEvents (After/AfterRules)
    // and we don't know which is the last one, perform the clean up in AfterClass.
-    private Map<Class<?>, Set<Object>> activatedTestContexts = new HashMap<Class<?>, Set<Object>>();
+    private Map<Class<?>, Set<Object>> activatedTestContexts = new ConcurrentHashMap<>();


This seems to already be guarded by itself. I don't think we need to change the type.

jamezp · 2025-04-16T23:41:21Z

.../src/main/java/org/jboss/arquillian/container/test/impl/client/ContainerEventController.java


        ContainerRegistry containerRegistry = this.containerRegistry.get();
-        DeploymentScenario deploymentScenario = this.deploymentScenario.get();
+        DeploymentScenario deploymentScenario = Objects.requireNonNull(this.deploymentScenario.get(), "deploymentScenario cannot be null");


I'm not sure what we gain here.

not much I was using this as a marker as the main issue I have with parallel tests is the NPE here

Ah okay. I would think then that there is likely an issue activating the context in a multi-threaded environment. That's typically when null would be returned there. IIRC the context is a ThreadLocal map of some sort.

jamezp · 2025-04-16T23:42:52Z

...i/src/main/java/org/jboss/arquillian/container/spi/client/deployment/DeploymentScenario.java


    public DeploymentScenario() {
-        this.deployments = new ArrayList<Deployment>();
+        this.deployments = new CopyOnWriteArrayList<>();


More is likely needed here to really be thread-safe. Especially in the findDefaultDeployment method.

olamy · 2025-04-17T08:35:57Z

Overall I think this is a good idea to make Arquillian more thread-safe. However, I do think it will be quite a task to do so.

Yup I agree :)
I don't have a deep knowledge of the internal of core so I have just started small steps at least there is an easy way to reproduce the problem.

starksm64 · 2025-06-05T06:51:12Z

The core layer with its single thread event dispatch is inherently not threadsafe. The same for the container layer. We will have to target this in the 2.0 release when we look at how the runners introduce parallel tests in the lifecycle and move away from the event dispatch approach.

olamy · 2025-06-06T05:03:30Z

oh yup sure. Sorry I didn't reallly look deeply into it but definitely sounds like more big changes to ArrayList to CopyOnWriteArrayList

Signed-off-by: Olivier Lamy <olamy@apache.org>

olamy force-pushed the tck-multithread-failures branch 2 times, most recently from 05837e2 to b22f1d1 Compare April 4, 2025 01:19

olamy force-pushed the tck-multithread-failures branch from b22f1d1 to f323e49 Compare April 16, 2025 00:26

jamezp reviewed Apr 16, 2025

View reviewed changes

rhusar added the hold label May 22, 2025

olamy added 4 commits July 29, 2025 09:48

investigate junit5 multi thread build failure Servlet TCK with Jetty

9a3c8ce

Signed-off-by: Olivier Lamy <olamy@apache.org>

more thread safe collections

70ad30a

Signed-off-by: Olivier Lamy <olamy@apache.org>

not sure about those but some thread safe fields

d2f22bf

Signed-off-by: Olivier Lamy <olamy@apache.org>

revert non working change

2689ad8

Signed-off-by: Olivier Lamy <olamy@apache.org>

olamy force-pushed the tck-multithread-failures branch from f323e49 to 2689ad8 Compare July 28, 2025 23:48

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] tck multithread failures #673

[WIP] tck multithread failures #673

Uh oh!

olamy commented Feb 4, 2025

Uh oh!

rhusar commented Feb 7, 2025

Uh oh!

olamy commented Feb 8, 2025 •

edited

Loading

Uh oh!

jamezp left a comment

Uh oh!

jamezp Apr 16, 2025

Uh oh!

jamezp Apr 16, 2025

Uh oh!

jamezp Apr 16, 2025

Uh oh!

olamy Apr 17, 2025

Uh oh!

jamezp Apr 17, 2025 •

edited

Loading

Uh oh!

jamezp Apr 16, 2025

Uh oh!

olamy commented Apr 17, 2025 •

edited

Loading

Uh oh!

starksm64 commented Jun 5, 2025

Uh oh!

olamy commented Jun 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

[WIP] tck multithread failures #673

Are you sure you want to change the base?

[WIP] tck multithread failures #673

Uh oh!

Conversation

olamy commented Feb 4, 2025

Short description of what this resolves:

Changes proposed in this pull request:

Uh oh!

rhusar commented Feb 7, 2025

Uh oh!

olamy commented Feb 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jamezp left a comment

Choose a reason for hiding this comment

Uh oh!

jamezp Apr 16, 2025

Choose a reason for hiding this comment

Uh oh!

jamezp Apr 16, 2025

Choose a reason for hiding this comment

Uh oh!

jamezp Apr 16, 2025

Choose a reason for hiding this comment

Uh oh!

olamy Apr 17, 2025

Choose a reason for hiding this comment

Uh oh!

jamezp Apr 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jamezp Apr 16, 2025

Choose a reason for hiding this comment

Uh oh!

olamy commented Apr 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

starksm64 commented Jun 5, 2025

Uh oh!

olamy commented Jun 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

olamy commented Feb 8, 2025 •

edited

Loading

jamezp Apr 17, 2025 •

edited

Loading

olamy commented Apr 17, 2025 •

edited

Loading