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

Reply via email to