[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17518507#comment-17518507
]
Tibor Digana edited comment on SUREFIRE-2029 at 4/6/22 11:12 PM:
-----------------------------------------------------------------
Acctualy ,the documentation talks about this risk.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
Configuration:
{noformat}
<forkCount>3</forkCount>
{noformat}
{noformat}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.
{noformat}
So, essentially, it says that you have 2 modules at least, two modules may run
in parallel, and each surefire plugin has the same config forkNumber=2.
was (Author: tibor17):
Acctualy ,the documentation talks about this risk.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
Configuration:
{noformat}
<forkCount>3</forkCount>
{noformat}
{noformat}
In case of a multi module project with tests in different modules, you could
also use, say, mvn -T 2 ... to start the build, yielding values for
${surefire.forkNumber} ranging from 1 to 6.
{noformat}
> Parallel execution but surefire.forkNumber is the same
> ------------------------------------------------------
>
> Key: SUREFIRE-2029
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2029
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
> Affects Versions: 2.22.2
> Reporter: Nathan McDonald
> Priority: Minor
> Fix For: waiting-for-apache-feedback
>
>
> We have a multi module maven project, and due to our legacy architecture
> different modules are using the same underlying database.
> We are using the one db per fork strategy mentioned, and each test clears the
> database before running its test.
> This seems to work fine. But when running the full build on azure with:
> {noformat}
> mvn ... -T 1C -pl {modulesToBuild} -amd{noformat}
>
> See output kicking off build like:
> {noformat}
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of
> 8{noformat}
>
> We occasionally see one long running test fail, and have traced cause that
> another test is running in parallel and clearing the database before long
> running test completes . This would only seem to be possible if parallel
> forks running but same surefire.forkNumber being set for multiple forks.
> Outputting logs of when tests start and end, with log outputting
> "Thread#$threadId\{$forkNumber}, e.g. Thread#7\{3} for thread with id 7,
> where surefire.forkNumber is 3
> Looking at logs we can see test starts on thread/fork 1, clears db as
> expected, and 30 seconds later logs that it completes (with error that is
> shown later).
> But we can see just moments later, another test starts up and also clears the
> database, but is using same thread/fork:
> {noformat}
> 2022-03-01T16:30:59.5953417Z 2022-03-01 16:30:59.585 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:30:59.7150510Z 2022-03-01 16:30:59.711 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:78 - Thread#1{1} - running
> setup for
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> …
> {noformat}
> 2022-03-01T16:31:01.1305751Z 2022-03-01 16:31:01.128 [main] INFO
> e.t.b.h.w.c.AbstractIT:556 - Thread#1{1} - Clearing the database before test
> 2022-03-01T16:31:01.6123984Z [INFO] Tests run: 2, Failures: 0, Errors: 0,
> Skipped: 0, Time elapsed: 24.715 s - in
> e.t.b.h.w.c.FinancialStatementReportItemRestControllerIT
> 2022-03-01T16:31:01.6124965Z [INFO] Running
> e.t.b.h.w.c.KeyInformationRestControllerIT{noformat}
> …
> {noformat}
> 2022-03-01T16:31:29.1656587Z 2022-03-01 16:31:29.164 [main] INFO
> e.t.b.a.w.c.AnalysisJobDownloadControllerTest:94 - Thread#1{1} - complete
> test
> AnalysisJobDownloadControllerTest#downloadTransactionsAfterAppendingDuplicateRecords{noformat}
> This isn't consistent though. Can see other cases where this works, but the
> logs found where it is working can see long running test running on separate
> fork:
> Thread#1\{3}
> Obviously there are separate threads/forks running here, so seems like
> somewhere between maven multi module and -T 1C, there is not always
> assigning unique forkNumber to each fork.
> I figure best practice is probably having separate modules not use same db,
> so possibly this issue is existing but not being hit by people as would only
> cause issue if same fork number used for separate modules on different
> databases.
> Still looking into issue our side will update if find workaround or more
> detailed information.
> Our surefire/failsafe config is in the root inherited by all other sub
> modules:
> {code:java}
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-surefire-plugin</artifactId>
> <configuration>
> <forkCount>2</forkCount>
> <argLine>@{argLine} -DforkNumber=${surefire.forkNumber}</argLine>
> <trimStackTrace>false</trimStackTrace>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-failsafe-plugin</artifactId>
> <configuration>
> <forkCount>1</forkCount>
> <argLine>@{argLine} -DforkNumber=${surefire.forkNumber}</argLine>
> <trimStackTrace>false</trimStackTrace>
>
> <reportsDirectory>${project.build.directory}/surefire-reports</reportsDirectory>
> </configuration>
> <executions>
> <execution>
> <goals>
> <goal>integration-test</goal>
> <goal>verify</goal>
> </goals>
> </execution>
> </executions>
> </plugin>{code}
> mvn version info:
> {noformat}
> Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
> Maven home: /usr/local/apache-maven
> Java version: 11.0.13, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-11-openjdk-11.0.13.0.8-1.el7_9.x86_64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-1160.53.1.el7.x86_64", arch: "amd64",
> family: "unix"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
