[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519406#comment-17519406
]
Nathan McDonald commented on SUREFIRE-2029:
---
Trying the workaround suggested, add config to failsafe:
@{argLine}
-DforkNumber=${surefire.forkNumber}${project.artifactId}
Seems to fix our issue, ensures each module has it's db isolated from another,
and then if we again fork with failsafe the forkNumber will be unique within
module.
Thanks for all response, very complex issue but has a viable workaround
> 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}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {code}
> mvn version info:
> {noformat}
> Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
> Maven home: /usr/local/apache-maven
> Java
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518917#comment-17518917
]
Tibor Digana commented on SUREFIRE-2029:
Sharing *AtomicInteger *would be possible with
{code:java}
MavenSession.getExecutionProperties()
{code}
It has to be some Java API object and the key value must be in the form of
expression.
The internal forkCount would be shifted by the previous shifts of concurrent
modules started before.
> 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}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {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:
>
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518886#comment-17518886
]
Tibor Digana commented on SUREFIRE-2029:
[~milosh]
Andreas Gudian [~agudian] created this feature. If he meant some guarantees
about isolated projects and -T parameter, coherent behavior across them and
unique numbers, he would implement it so several years ago. He did not mean the
same what you mean now.
He was my colleague in ASF and we talked about it. We know for long time these
guarantees do not exist.
He wanted to say that the user should not expect limitations in terms of
concurrent JVMs due to these are also controlled by the Maven Core in terms of
parallel modules and the modules are independent, see this sentence:
{noformat}
Maven core allows building modules of multi-module projects in parallel with
the command line option -T. This multiplies the extent of concurrency
configured directly in maven-surefire-plugin.
{noformat}
So, something is under control of the core and some concurrency is controlled
by surefire and the outcome may mean that there would be more than 3 concurrent
JVMs. Maybe 3, maybe 3*N, or even 1 to 3*N.
> 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
>
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518510#comment-17518510
]
Nathan McDonald commented on SUREFIRE-2029:
---
That's not how I read the documentation. It says you have fork count in
failsafe configured to 3. But then with -T 2, this is saying you get numbers 1
through 6, implying that -T2 splits off 2 forks for multi module builds. each
of those forks can then run parallel builds that could then create 3 forks
each, resulting in 6 forks (1 through 6).
If mvn -T is not supported, then surely documentation should state that in case
where fork count is 3, and mvn -T 2 is used, then ${surefire.forkNumber}
ranging from 1 to 3 (where same forkNumber could be used in different modules
running in different forks)
> 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}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518507#comment-17518507
]
Tibor Digana commented on SUREFIRE-2029:
Acctualy ,the documentation talks about this risk.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
Configuration:
{noformat}
3
{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}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {code}
> mvn version info:
> {noformat}
> Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
> Maven
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518448#comment-17518448
]
Tibor Digana commented on SUREFIRE-2029:
I understand that you want to reach one unique number. It would mean that the
plugin must have a responsibility for the plugins in another POMs, their plugin
executions and Maven execution itself. If anything is changed in Maven, we
have to change this feature in surefire as well. If it happens, it means that
we created unnecessary coupling which is unwanted.
If you want to associate the plugin execution with the name of SQL database, I
would recommend you to use {{project.artifactId}} combined with {{forkNumber}}.
The artifactIds are typically unique in multimodule projects.
Can you guys [~famod] [~milosh] check it out? The interpolation with artifactId
is not supported yet, I guess.
> 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}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
>
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516705#comment-17516705
]
Falko Modler commented on SUREFIRE-2029:
{quote}If you use parallel Maven build, i.e. -T... , the forkNumbers may
repeat.{quote}
A mere _repetition_ during the course of an entire multi-module build is not a
problem for me, but that you can end up with the same number in two
_concurrently_ running modules/test JVM forks is what bothers me/us.
> 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}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {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:
>
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516700#comment-17516700
]
Nathan McDonald commented on SUREFIRE-2029:
---
That would explain issue, but then seems to go against what's documented:
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html]
After showing pom with
{code:java}
3{code}
Then states:
{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}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {code}
> mvn version info:
> {noformat}
> Apache Maven
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515847#comment-17515847
]
Tibor Digana commented on SUREFIRE-2029:
If you use parallel Maven build, i.e. -T... , the forkNumbers may repeat.
The reason is that the idea behind Maven assumes that plugins are very isolated
and should not have any notion about the surrounding world, basically.
So I guess, the execution would be safe if you avoid using -T ...
See our integration test ForkModeIT and the pattern
{noformat}
"testValue_${surefire.threadNumber}_${surefire.forkNumber}"
{noformat}
which is resolved to testValue_1_1.
It is a combination of parallel test and parallel forks.
If the Maven API provides us with -T number on particular POm execution, we may
extend this patter. This was incremental work in passed as well.
> 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
>
> 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}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515793#comment-17515793
]
Falko Modler commented on SUREFIRE-2029:
[~tibordigana] do you have an idea what might have broken this?
> 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
>
> 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}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {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)
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500615#comment-17500615
]
Nathan McDonald commented on SUREFIRE-2029:
---
Ah thanks forgot to include that, it's version 3.8.2. added to description of
issue
> 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
>
> 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}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {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)
[jira] [Commented] (SUREFIRE-2029) Parallel execution but surefire.forkNumber is the same
[
https://issues.apache.org/jira/browse/SUREFIRE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500368#comment-17500368
]
Falko Modler commented on SUREFIRE-2029:
I think I'm seeing something similar (with maven-surefire-plugin). Which Maven
version are you using?
> 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
>
> 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}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> 2
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>
> 1
> @{argLine} -DforkNumber=${surefire.forkNumber}
> false
>
> ${project.build.directory}/surefire-reports
>
>
>
>
> integration-test
> verify
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
