4.0.0
org.glassfish.jersey.tests.memleaks.redeployment
project
2.41-SNAPSHOT
redeployment-threadlocals-app
war
jersey-tests-memleak-redeployment-threadlocals-app
This project shows that not careful use of ThreadLocal in a thread-pool environment is a risk. In this case, memory leaks
may occur under certain circumstances.
Known cases when memory leaks do happen:
[1] Tomcat with deployment by using its admin REST API (copying to webapps dir does not cause a memory leak since the
initialization of the application is done by a different thread, which might get eventually discarded.)
[2] Glassfish - probably works due to a fact, that HK2 is not used (as opposed to redeployment-no-jersey-test-app) and the
classes that participate on strong references to a GC root are loaded by webapp classloader.
To run this test threadlocals classloader memory leak example, execute from jersey root dir:
[1] Glassfish: mvn clean install -pl :redeployment-threadlocals-app -P gf4,memleak-leaking-test,memleak-redeployment
[2] Weblogic: mvn clean install -pl :redeployment-threadlocals-app -P wls,memleak-leaking-test,memleak-redeployment
[3] Tomcat: mvn clean install -pl :redeployment-threadlocals-app -P tomcat,memleak-leaking-test,memleak-redeployment
128m
hello
10000
200
${external.container.contextRoot}
tomcat
48m
memleak-leaking-test
org.codehaus.mojo
build-helper-maven-plugin
org.mortbay.jetty
jetty-maven-plugin
org.glassfish.jersey.test-framework.maven
container-runner-maven-plugin
org.apache.maven.plugins
maven-enforcer-plugin
enforce-out-of-memory-did-not-occur
${phase.redeployment.post-integration-test}
jakarta.servlet
jakarta.servlet-api
${servlet4.version}
provided