You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by bharath chinnadurai maharajan <bh...@googlemail.com> on 2013/12/11 20:36:40 UTC

Question on bug# 53267 in tomcat 7.0.47

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). It is also mentioned the value
is configurable using a system property -
org.apache.catalina.core.jreMemoryLeakPreventionGCDaemonPeriod.

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.

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.

Am I wrong to assume the config variable will be present in 7.0.47?

Thanks for your time, and my sincere apologies if I had wasted it.

--
Bharath.

Re: Question on bug# 53267 in tomcat 7.0.47

Posted by bharath chinnadurai maharajan <bh...@googlemail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: Question on bug# 53267 in tomcat 7.0.47

Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org