blob: 6dafdcedca11b0c80124e5ca26482477b9b919e3 [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) 2015, 2021 Oracle and/or its affiliates. All rights reserved.
This program and the accompanying materials are made available under the
terms of the Eclipse Public License v. 2.0, which is available at
http://www.eclipse.org/legal/epl-2.0.
This Source Code may also be made available under the following Secondary
Licenses when the conditions for such availability set forth in the
Eclipse Public License v. 2.0 are satisfied: GNU General Public License,
version 2 with the GNU Classpath Exception, which is available at
https://www.gnu.org/software/classpath/license.html.
SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0
-->
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.glassfish.jersey.tests.memleaks.redeployment</groupId>
<artifactId>project</artifactId>
<version>2.35-SNAPSHOT</version>
</parent>
<artifactId>redeployment-threadlocals-app</artifactId>
<packaging>war</packaging>
<name>jersey-tests-memleak-redeployment-threadlocals-app</name>
<description>
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
</description>
<properties>
<memleak.jvm.maxheap>128m</memleak.jvm.maxheap>
<external.container.contextRoot>hello</external.container.contextRoot>
<memleak.redeploy.count>10000</memleak.redeploy.count>
<memleak.redeploy.expectedStatus>200</memleak.redeploy.expectedStatus>
<memleak.redeploy.requestPathQuery>${external.container.contextRoot}</memleak.redeploy.requestPathQuery>
</properties>
<profiles>
<profile>
<id>tomcat</id>
<properties>
<memleak.jvm.maxheap>48m</memleak.jvm.maxheap>
</properties>
</profile>
<profile>
<id>memleak-leaking-test</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.glassfish.jersey.test-framework.maven</groupId>
<artifactId>container-runner-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<id>enforce-out-of-memory-did-not-occur</id>
<phase>${phase.redeployment.post-integration-test}</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
<dependencies>
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>${servlet4.version}</version>
<scope>provided</scope>
</dependency>
</dependencies>
</project>