atom feed8 messages in org.apache.tomcat.usersRe: JreMemoryLeakPreventionListener a...
FromSent OnAttachments
Donald ArmstrongAug 11, 2010 9:14 am 
Christopher SchultzAug 11, 2010 10:33 am 
Donald ArmstrongAug 11, 2010 5:05 pm 
Konstantin KolinkoAug 12, 2010 4:47 am 
Christopher SchultzAug 12, 2010 7:14 am 
Donald ArmstrongAug 12, 2010 2:04 pm 
Christopher SchultzAug 13, 2010 1:02 pm 
dona...@gmail.comAug 13, 2010 1:39 pm 
Subject:Re: JreMemoryLeakPreventionListener and hourly Full GC
From:Donald Armstrong (dona@gmail.com)
Date:Aug 12, 2010 2:04:20 pm
List:org.apache.tomcat.users

Thank you Konstantin and Chris for your attention.

As stated in the initial post: 'We have recently deployed tomcat-6.0.28 in our organization and are noticing every hour, a Full GC is occurring. The same application, same JVM, same JVM args, just a new tomcat release.'

Using the default JreMemoryLeakPreventionListener configuration that has 'gcDaemonProtection=true' will result in 1hr FullGCs using Sun 1.6 b18, b20 and b21on Solaris and Windows. We've tested and successfully 'contained' the FullGC behavior using one of the below configurations:

1) suppress the FullGC using JVM arg -XX:+DisableExplicitGC

2) keep the FullGC but to defer to the CMS collector using JVM arg -XX:+ExplicitGCInvokesConcurrent

3) <Listener
className="org.apache.catalina.core.JreMemoryLeakPreventionListener" gcDaemonProtection="false"/>

4) Disable the listener altogether

We've decided to go with option 3.

Thanks, Donnie

On Thu, Aug 12, 2010 at 9:15 AM, Christopher Schultz <chr@christopherschultz.net> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Konstantin,

On 8/12/2010 7:48 AM, Konstantin Kolinko wrote:

It looks that with your version of JRE and with your setting it is better to run with gcDaemonProtection="false".  I certainly do not know how other JRE versions behave here. (Feedback is welcomed).

That's what he's got, now: gcDaemonProtection="false" (see the OP), but the GC is still happening.

Donald, the reason the JreMemoryLeakPreventionListener makes the call to GC.requestLatency is to un-do the effect of some other component (RMI, it seems).

It's possible that some component other than the JreMemoryLeakPreventionListener is causing the periodic full GC.

Try disabling the listener altogether and see if the GCs go away.

If they don't, consider recompiling the JreMemoryLeakPreventionListener with some debugging code in there (the current code does not emit any logging unless there is a problem calling GC.requestLatency... it does not announce it's intention of doing so, even at a TRACE level).

- -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxkAfAACgkQ9CaO5/Lv0PBgjACgkeQyW4H949HJ/k+28hjKR3JH 9tsAoLIxzWfypWAhR9PzC4IQpGFF0Kwy =5GDP -----END PGP SIGNATURE-----