[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

Signed-off-by: Olivier Lamy <[email protected]>

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

@@ -59,7 +60,7 @@ public class TestContextHandler {

    // 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

    private void lookup(Method method, ResultCallback callback) {
        DeploymentTargetDescription deploymentTarget = locateDeployment(method);

        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

@@ -32,7 +34,7 @@ public class DeploymentScenario {
    private final List<Deployment> deployments;

    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.

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

olamy added 4 commits April 16, 2025 10:26

investigate junit5 multi thread build failure Servlet TCK with Jetty

12639f0

Signed-off-by: Olivier Lamy <[email protected]>

more thread safe collections

a91aa72

Signed-off-by: Olivier Lamy <[email protected]>

not sure about those but some thread safe fields

1f085ed

Signed-off-by: Olivier Lamy <[email protected]>

revert non working change

f323e49

Signed-off-by: Olivier Lamy <[email protected]>

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] tck multithread failures #673

[WIP] tck multithread failures #673

olamy commented Feb 4, 2025

rhusar commented Feb 7, 2025

olamy commented Feb 8, 2025 •

edited

Loading

jamezp left a comment

jamezp Apr 16, 2025

jamezp Apr 16, 2025

jamezp Apr 16, 2025

olamy Apr 17, 2025

jamezp Apr 17, 2025 •

edited

Loading

jamezp Apr 16, 2025

olamy commented Apr 17, 2025 •

edited

Loading

[WIP] tck multithread failures #673

Are you sure you want to change the base?

[WIP] tck multithread failures #673

Conversation

olamy commented Feb 4, 2025

Short description of what this resolves:

Changes proposed in this pull request:

rhusar commented Feb 7, 2025

olamy commented Feb 8, 2025 • edited Loading

jamezp left a comment

Choose a reason for hiding this comment

jamezp Apr 16, 2025

Choose a reason for hiding this comment

jamezp Apr 16, 2025

Choose a reason for hiding this comment

jamezp Apr 16, 2025

Choose a reason for hiding this comment

olamy Apr 17, 2025

Choose a reason for hiding this comment

jamezp Apr 17, 2025 • edited Loading

Choose a reason for hiding this comment

jamezp Apr 16, 2025

Choose a reason for hiding this comment

olamy commented Apr 17, 2025 • edited Loading

olamy commented Feb 8, 2025 •

edited

Loading

jamezp Apr 17, 2025 •

edited

Loading

olamy commented Apr 17, 2025 •

edited

Loading