Re: Memory leak with Jersey 2.33
Mark, On 2/1/2021 1:33 AM, Mark Thomas wrote: Is the GC root above the only one? I've seen similar behaviour in the past where weak references appear to be the cause of a leak but closer inspection uncovers a strong reference. Mark Thanks for putting me on the correct track. I'm using log4j2 2.14.0 and Jersey REST 2.33 which includes Jackson 2.11.3. Analyzing the heap dump using Eclipse MAT and excluding weak references led me down a fun rabbit hole. Leak 1: https://github.com/FasterXML/jackson-core/issues/400 Fix: in setenv.(bat/sh) add -Dcom.fasterxml.jackson.core.util.BufferRecyclers.trackReusableBuffers=true In a servlet context listener add int released = releaseBuffers(); // with the proper import, of course Leak 2: https://issues.apache.org/jira/browse/LOG4J2-578 Although it's marked as fixed, it apparently is not. Fix (for now): in setenv(bat/sh) add -Dlog4j2.disable.jmx=true With all of that done, undeploying the web application and doing a heap dump shows no traces of the offending app (all WebappClassLoaders have started=true). Again, thanks for the tip. . . . just my two cents. OpenPGP_signature Description: OpenPGP digital signature
Re: Memory leak with Jersey 2.33
On 01/02/2021 06:37, Mark Eggers wrote: > On 1/31/2021 9:39 PM, Mark Eggers wrote: >> GC roots for cplanapi are: >> >> class com.sun.naming.internal.ResourceManager >> '- propertiesCache java.util.WeakHashMap >> '- table java.util.WeakHashMap$Entry[16] >> '- java.util.WeakHashMap$Entry >> '- referent org.apache.catalina.loader.WebappClassLoader >> >> This occurs on both Windows and Linux, and with the above JRE as well >> as Java 1.8.0_202. >> >> . . . just my two cents >> /mde/ >> > > Please ignore this. Doing two rounds of GC through the manager removed > the application from memory (as confirmed by a heap dump). > > Now I need to figure out how to force a GC, since we had an OOM > Metaspace issue with repeated deployments of the application. Is the GC root above the only one? I've seen similar behaviour in the past where weak references appear to be the cause of a leak but closer inspection uncovers a strong reference. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Memory leak with Jersey 2.33
On 1/31/2021 9:39 PM, Mark Eggers wrote: Folks, This is probably not a Tomcat issue, but any thoughts on how to resolve this would be greatly appreciated. I am running into an apparent ClassLoader leak with the following configuration: Windows 10 Professional (64 bit, latest updates) OpenJDK 11.0.10 Apache Tomcat 7.0.107 Jersey Rest 2.33 I have a simple application: ApplicationConfig: @ApplicationPath("/service") public class ApplicationConfig extends Application { public ApplicationConfig() { } @Override public Set> getClasses(){ Set> resources = new java.util.HashSet<>(); resources.add(org.mdeggers.cplanapi.resource.CostInfoResource.class); resources.add(org.mdeggers.cplanapi.resource.InstituteInfoResource.class); resources.add(org.mdeggers.cplanapi.resource.InstituteTypeInfoResource.class); resources.add(org.mdeggers.cplanapi.mapper.NotFoundExceptionMapper.class); return resources; } } One of three resources: @Path("/v1/inst") public class InstituteInfoResource { public InstituteInfoResource() { } @GET @Path("/info") @Produces({MediaType.APPLICATION_JSON}) public InstituteContainer getNationalList() { InstituteInfo instituteinfo = new InstituteInfo(); return instituteinfo.getNational(); } @GET @Path("/info/{ state : [A-Z]{2} }") @Produces({MediaType.APPLICATION_JSON}) public InstituteContainer getStateList(@PathParam("state") String state) { InstituteInfo instituteinfo = new InstituteInfo(); return instituteinfo.getState(state); } } The InstituteInfo class is a DAO that makes requests into a MySQL database and returns a container with the information. This all works, but on undeploying the Tomcat Manager complains that there is a leak after unloading the web application. Doing a heap dump and looking at it with the following OQL in Eclipse MAT shows that the application still resides in memory, with started=false. SELECT wcl.contextName.toString() AS contextName, wcl.started AS started, wcl.@retainedHeapSize AS retainedSize FROM org.apache.catalina.loader.WebappClassLoader wcl contextName started retainedSize /cplanapi false 586,720 /docs true 46,664 /host-manager true 47,288 /manager true 47,392 /examples true 85,432 true 46,912 GC roots for cplanapi are: class com.sun.naming.internal.ResourceManager '- propertiesCache java.util.WeakHashMap '- table java.util.WeakHashMap$Entry[16] '- java.util.WeakHashMap$Entry '- referent org.apache.catalina.loader.WebappClassLoader This occurs on both Windows and Linux, and with the above JRE as well as Java 1.8.0_202. . . . just my two cents /mde/ Please ignore this. Doing two rounds of GC through the manager removed the application from memory (as confirmed by a heap dump). Now I need to figure out how to force a GC, since we had an OOM Metaspace issue with repeated deployments of the application. . . . just my two cents /mde/ OpenPGP_signature Description: OpenPGP digital signature
Memory leak with Jersey 2.33
Folks, This is probably not a Tomcat issue, but any thoughts on how to resolve this would be greatly appreciated. I am running into an apparent ClassLoader leak with the following configuration: Windows 10 Professional (64 bit, latest updates) OpenJDK 11.0.10 Apache Tomcat 7.0.107 Jersey Rest 2.33 I have a simple application: ApplicationConfig: @ApplicationPath("/service") public class ApplicationConfig extends Application { public ApplicationConfig() { } @Override public Set> getClasses(){ Set> resources = new java.util.HashSet<>(); resources.add(org.mdeggers.cplanapi.resource.CostInfoResource.class); resources.add(org.mdeggers.cplanapi.resource.InstituteInfoResource.class); resources.add(org.mdeggers.cplanapi.resource.InstituteTypeInfoResource.class); resources.add(org.mdeggers.cplanapi.mapper.NotFoundExceptionMapper.class); return resources; } } One of three resources: @Path("/v1/inst") public class InstituteInfoResource { public InstituteInfoResource() { } @GET @Path("/info") @Produces({MediaType.APPLICATION_JSON}) public InstituteContainer getNationalList() { InstituteInfo instituteinfo = new InstituteInfo(); return instituteinfo.getNational(); } @GET @Path("/info/{ state : [A-Z]{2} }") @Produces({MediaType.APPLICATION_JSON}) public InstituteContainer getStateList(@PathParam("state") String state) { InstituteInfo instituteinfo = new InstituteInfo(); return instituteinfo.getState(state); } } The InstituteInfo class is a DAO that makes requests into a MySQL database and returns a container with the information. This all works, but on undeploying the Tomcat Manager complains that there is a leak after unloading the web application. Doing a heap dump and looking at it with the following OQL in Eclipse MAT shows that the application still resides in memory, with started=false. SELECT wcl.contextName.toString() AS contextName, wcl.started AS started, wcl.@retainedHeapSize AS retainedSize FROM org.apache.catalina.loader.WebappClassLoader wcl contextName started retainedSize /cplanapi false586,720 /docs true 46,664 /host-manager true 47,288 /manager true 47,392 /examples true 85,432 true 46,912 GC roots for cplanapi are: class com.sun.naming.internal.ResourceManager '- propertiesCache java.util.WeakHashMap '- table java.util.WeakHashMap$Entry[16] '- java.util.WeakHashMap$Entry '- referent org.apache.catalina.loader.WebappClassLoader This occurs on both Windows and Linux, and with the above JRE as well as Java 1.8.0_202. . . . just my two cents /mde/ OpenPGP_signature Description: OpenPGP digital signature