[
https://issues.apache.org/jira/browse/SUREFIRE-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic updated SUREFIRE-2186:
--------------------------------------
Description:
It is not possible to run a very extensive test suite with the current version
of surefire when you reuse the forks.
This used to work with surefire 2.22.2, and it's leaking with 3.1.2
In ActiveMQ Artemis, we have thousands of integration tests and we reuse the
forks otherwise it would take an infinite amount of time to complete the test
suite. and we had to revert to surefire 2.22.2 until this leak is resolved.
One obvious leak I see is
org.apache.maven.surefire.api.util.internal.ClassMethod being held by
ClassMethodIndexer, which is being held by Junit4RunListener.
Also, a bit scary the fact that ClassMethodIndexer is using a non static
ThreadLocal. even though this is not holding ClassMethod instances, but since
my complain is the test suite not being able to finish with the new SureFire
maybe this is also causing issues.
I have been doing fine on pursuing leaks (even though it's not my main
professional attribution :) but I created a pet project just for that purpose,
if someone is interested in fixing this I will be certainly up to help fixing
or even fixing it myself if I'm provided some guidance as I'm new to this
codebase)
To reproduce the ClassMethod leak validation, you should follow these steps:
git clone https://github.com/clebertsuconic/surefire-reproducer.git
cd surefire-reproducer
mvn install
The surefire-reproducer is using check-leak to count the number of ClassMethod
instances in the HEAP.
Notice there might be other leaks like the one I mentioned with the non static
ThreadLocal. Or even Junit4Listener itself. as I think the instance should be
released at the end of the test.
BTW: Non static thread local is an anti-pattern. For example:
https://errorprone.info/bugpattern/ThreadLocalUsage
There are probably valid usecases with non static threadLocals, but I haven't
seen one that couldn't be avoided.
was:
It is not possible to run a very extensive test suite with the current version
of surefire when you reuse the forks.
This used to work with surefire 2.22.2, and it's leaking with 3.1.2
In ActiveMQ Artemis, we have thousands of integration tests and we reuse the
forks otherwise it would take an infinite amount of time to complete the test
suite. and we had to revert to surefire 2.22.2 until this leak is resolved.
One obvious leak I see is
org.apache.maven.surefire.api.util.internal.ClassMethod is being held by
ClassMethodIndexer, which is being held by Junit4RunListener.
Also, a bit scary the fact that ClassMethodIndexer is using a non static
ThreadLocal. even though this is not causing this particular leak, but since my
complain is the test suite not being able to finish with the new SureFire maybe
this is also causing issues.
I have been doing fine on pursuing leaks (even though it's not my main
professional attribution :) but I created a pet project just for that purpose,
if someone is interested in fixing this I will be certainly up to help fixing
or even fixing it myself if I'm provided some guidance as I'm new to this
codebase)
To reproduce the ClassMethod leak validation, you should follow these steps:
git clone https://github.com/clebertsuconic/surefire-reproducer.git
cd surefire-reproducer
mvn install
The surefire-reproducer is using check-leak to count the number of ClassMethod
instances in the HEAP.
Notice there might be other leaks like the one I mentioned with the non static
ThreadLocal. Or even Junit4Listener itself. as I think the instance should be
released at the end of the test.
BTW: Non static thread local is an anti-pattern. For example:
https://errorprone.info/bugpattern/ThreadLocalUsage
There are probably valid usecases with non static threadLocals, but I haven't
seen one that couldn't be avoided.
> Leaks in Surefire when reusing the fork
> ---------------------------------------
>
> Key: SUREFIRE-2186
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2186
> Project: Maven Surefire
> Issue Type: Bug
> Reporter: Clebert Suconic
> Priority: Major
>
> It is not possible to run a very extensive test suite with the current
> version of surefire when you reuse the forks.
> This used to work with surefire 2.22.2, and it's leaking with 3.1.2
> In ActiveMQ Artemis, we have thousands of integration tests and we reuse the
> forks otherwise it would take an infinite amount of time to complete the test
> suite. and we had to revert to surefire 2.22.2 until this leak is resolved.
> One obvious leak I see is
> org.apache.maven.surefire.api.util.internal.ClassMethod being held by
> ClassMethodIndexer, which is being held by Junit4RunListener.
> Also, a bit scary the fact that ClassMethodIndexer is using a non static
> ThreadLocal. even though this is not holding ClassMethod instances, but since
> my complain is the test suite not being able to finish with the new SureFire
> maybe this is also causing issues.
> I have been doing fine on pursuing leaks (even though it's not my main
> professional attribution :) but I created a pet project just for that
> purpose, if someone is interested in fixing this I will be certainly up to
> help fixing or even fixing it myself if I'm provided some guidance as I'm new
> to this codebase)
> To reproduce the ClassMethod leak validation, you should follow these steps:
> git clone https://github.com/clebertsuconic/surefire-reproducer.git
> cd surefire-reproducer
> mvn install
> The surefire-reproducer is using check-leak to count the number of
> ClassMethod instances in the HEAP.
> Notice there might be other leaks like the one I mentioned with the non
> static ThreadLocal. Or even Junit4Listener itself. as I think the instance
> should be released at the end of the test.
> BTW: Non static thread local is an anti-pattern. For example:
> https://errorprone.info/bugpattern/ThreadLocalUsage
> There are probably valid usecases with non static threadLocals, but I haven't
> seen one that couldn't be avoided.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)