FISH-8672 bugfix: removed class loader leaks

[lprimak]

Description

Fixes ClassLoader leaks
fixes #6554 (partial fix, performance isn't addressed, just leaks)
fixes #6301
fixes #4098

Important Info

Testing

Tested with appserver/tests/payara-samples/classloader-data-api leak tester app and VisualVM

Testing Environment

Any

[RInverid]

Testing locally, this MR does not address the memory issues mentioned in #6554

[lprimak]

@RInverid Can you please elaborate? Do you have a reproducer that you are using?
Do you have any "GC Root" output from VisualVM?

My applications that I am testing with may not hit all of the leaks you are experiencing, as it doesn't use all of Jakarta EE APIs and only simple configurations.

Thank you for your help.

[lprimak]

You can also use this pre-built binary: https://nexus.hope.nyc.ny.us/repository/maven-releases/fish/payara/distributions/payara/6.2024.5-9/payara-6.2024.5-9.zip
Docker image is also available: docker pull lprimak/payara-full

[lprimak]

Found more leaks in Jax-RS EJB, and EAR deployment code. Should be fixed now.

[RInverid]

@RInverid Can you please elaborate? Do you have a reproducer that you are using? Do you have any "GC Root" output from VisualVM?

My applications that I am testing with may not hit all of the leaks you are experiencing, as it doesn't use all of Jakarta EE APIs and only simple configurations.

Thank you for your help.

I have our own application that I'm testing deployment time and memory usage on, which is how I found the commit that caused #6554 . I'll re-run with your updated branch and let you know the results!

[RInverid]

Update: the issue of too much memory usage & long deployment time is still present for me

[lprimak]

Update: the issue of too much memory usage & long deployment time is still present for me

The performance regression is not in scope for this PR.

All my applications run without memory leaks now and can be redeployed 1000s of times without running out of memory.
As I said before, they don't touch all of Payara's features and there may be another leak that isn't detected here.

What I suggest is to either provide a simple reproducer that shows the leak, or a "GC Root" screenshot from ClassLoader so I can be of some help.

There is also a possibility that your application or your setup is leaking memory somehow as well.

[lprimak]

I did test with reproducer from #6554 and that works without leaks now.

[lprimak]

Looks like #6637 introduced a regression. There are now dangling threads, and this PR needs to be updated to make class ContainerBackgroundSessionProcessor static as well

[lprimak]

Fixed regressions. Ready to go.