[jira] [Updated] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same

["Tibor Digana (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tibor Digana updated SUREFIRE-2029:
-----------------------------------
    Fix Version/s: waiting-for-feedback

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