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
Rate limiting
Hi, How do I limit request rates using Tomcat 9.0.x? Something similar to limit_req in nginx: https://www.nginx.com/blog/rate-limiting-nginx/ Martynas atomgraph.com - 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 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
