Hi Mark, Thanks for the quick reply. That explains. I should have looked into comment 11, my bad.
-- Bharath On Wed, Dec 11, 2013 at 2:52 PM, Mark Thomas <ma...@apache.org> wrote: > On 11/12/2013 19:36, bharath chinnadurai maharajan wrote: > > Hello, > > This is my first post to the tomcat forum, so please excuse of any > errors. > > > > I am looking at a fix for one of the bug (bug id#53267) in Catalina. Ref > - > > https://issues.apache.org/bugzilla/show_bug.cgi?id=53267 > > > > The bug is in RESOLVED FIXED state. > > > > As per this bug, the one hr time interval (when a GC event is kicked off) > > was changed to Long.MAX ( a very long time). > > No it wasn't. Long.MAX_VALUE has a special meaning. It was changed to > Long.MAX_VALUE-1 > > > It is also mentioned the value > > is configurable using a system property - > > org.apache.catalina.core.jreMemoryLeakPreventionGCDaemonPeriod. > > It is also mention that the addition of the system property was reverted. > > > When I tried setting this property to 3600000, assuming a full GC will be > > kicked every hour it did not happen. Curious, I looked into the code for > > version 7.0.47, that config variable was not used in > > org.apache.catalina.core.JreMemoryLeakPreventionListener. > > As intended. > > > Code snippet from JreMemoryLeakPreventionListener in tomcat version > 7.0.47 : > > > > Class<?> clazz = Class.forName("sun.misc.GC"); > > Method method = clazz.getDeclaredMethod( > > "requestLatency", > > new Class[] {long.class}); > > method.invoke(null, Long.valueOf(Long.MAX_VALUE - > > 1)); > > > > Instead of using the Long.MAX_VALUE-1 by default, it should try and > resolve > > if from the aforementioned system property. > > No it should not. This code does not exist to enable you to set a > regular interval for GC. If you want to do that you need to write your > own code to do so. > > > Am I wrong to assume the config variable will be present in 7.0.47? > > Yes. > > > Thanks for your time, and my sincere apologies if I had wasted it. > > I suggest you read the thread linked from comment 11 and look at commits > mentioned in the report. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
