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