[
https://issues.apache.org/jira/browse/LOG4J2-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-2921:
--------------------------------
Description:
One area to improve the execution time of our builds is to [enable parallel
test
execution|https://junit.org/junit5/docs/current/user-guide/#writing-tests-parallel-execution]
for all tests that can support that. Parallel tests are run in multiple
threads on the same JVM rather than in forked JVMs (our current configuration).
Thus, any tests that don't rely on JVM-global state (e.g., does not use
environment variables, system properties, changing the default locale, shares
an output file, etc.) should be able to support parallel test execution.
Considering the amount of overhead introduced by JVM forks for every test, I'd
hypothesize that this change could shave off at least 5-10 minutes from the
total build time.
JUnit 5 provides the ResourceLock annotation which can be used to create
generic locks (similar to ReadWriteLock in Java) for various resources. It
defines some default ones like for setting the locale, system properties,
system out, system error, and the timezone. Any other shared resources outside
those contexts could likely use custom string values for the annotation.
h3. Custom Resources
* {{log4j2.MarkerManager}} (since MarkerManager uses a static map, tests that
create non-trivial markers may interfere with each other)
* {{log4j2.StatusLogger}} (covers both changing the logger level as well as
relying on StatusData entries in the logger)
* {{log4j2.TestLogger}} (this test class maintains static state)
* {{log4j2.LoggerContextFactory}} (for tests that change
LogManager.setFactory() or depend on the currently configured
LoggerContextFactory via LogManager methods)
* {{java.lang.SecurityManager}} (for tests setting a SecurityManager)
was:
One area to improve the execution time of our builds is to [enable parallel
test
execution|https://junit.org/junit5/docs/current/user-guide/#writing-tests-parallel-execution]
for all tests that can support that. Parallel tests are run in multiple
threads on the same JVM rather than in forked JVMs (our current configuration).
Thus, any tests that don't rely on JVM-global state (e.g., does not use
environment variables, system properties, changing the default locale, shares
an output file, etc.) should be able to support parallel test execution.
Considering the amount of overhead introduced by JVM forks for every test, I'd
hypothesize that this change could shave off at least 5-10 minutes from the
total build time.
JUnit 5 provides the ResourceLock annotation which can be used to create
generic locks (similar to ReadWriteLock in Java) for various resources. It
defines some default ones like for setting the locale, system properties,
system out, system error, and the timezone. Any other shared resources outside
those contexts could likely use custom string values for the annotation.
h3. Custom Resources
* {{log4j2.MarkerManager }}(since MarkerManager uses a static map, tests that
create non-trivial markers may interfere with each other)
* {{log4j2.StatusLogger }}(covers both changing the logger level as well as
relying on StatusData entries in the logger)
* {{log4j2.TestLogger }}(this test class maintains static state)
* {{log4j2.LoggerContextFactory }}(for tests that change
LogManager.setFactory() or depend on the currently configured
LoggerContextFactory via LogManager methods)
* {{java.lang.SecurityManager }}(for tests setting a SecurityManager){{}}
> Enable parallel test execution for compatible tests
> ---------------------------------------------------
>
> Key: LOG4J2-2921
> URL: https://issues.apache.org/jira/browse/LOG4J2-2921
> Project: Log4j 2
> Issue Type: Improvement
> Components: Build, Tests
> Reporter: Matt Sicker
> Assignee: Matt Sicker
> Priority: Major
>
> One area to improve the execution time of our builds is to [enable parallel
> test
> execution|https://junit.org/junit5/docs/current/user-guide/#writing-tests-parallel-execution]
> for all tests that can support that. Parallel tests are run in multiple
> threads on the same JVM rather than in forked JVMs (our current
> configuration). Thus, any tests that don't rely on JVM-global state (e.g.,
> does not use environment variables, system properties, changing the default
> locale, shares an output file, etc.) should be able to support parallel test
> execution. Considering the amount of overhead introduced by JVM forks for
> every test, I'd hypothesize that this change could shave off at least 5-10
> minutes from the total build time.
> JUnit 5 provides the ResourceLock annotation which can be used to create
> generic locks (similar to ReadWriteLock in Java) for various resources. It
> defines some default ones like for setting the locale, system properties,
> system out, system error, and the timezone. Any other shared resources
> outside those contexts could likely use custom string values for the
> annotation.
> h3. Custom Resources
> * {{log4j2.MarkerManager}} (since MarkerManager uses a static map, tests
> that create non-trivial markers may interfere with each other)
> * {{log4j2.StatusLogger}} (covers both changing the logger level as well as
> relying on StatusData entries in the logger)
> * {{log4j2.TestLogger}} (this test class maintains static state)
> * {{log4j2.LoggerContextFactory}} (for tests that change
> LogManager.setFactory() or depend on the currently configured
> LoggerContextFactory via LogManager methods)
> * {{java.lang.SecurityManager}} (for tests setting a SecurityManager)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
