> -----Original Message-----
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Monday, August 27, 2012 3:55 PM
> To: Tomcat Developers List
> Subject: Re: svn commit: r1377689 -
> /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe
> ner.java
>
> On 27/08/2012 22:48, Filip Hanik (mailing lists) wrote:
> >
> >
> >> -----Original Message-----
> >> From: Mark Thomas [mailto:ma...@apache.org]
> >> Sent: Monday, August 27, 2012 3:44 PM
> >> To: Tomcat Developers List
> >> Subject: Re: svn commit: r1377689 -
> >>
> /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe
> >> ner.java
> >>
> >> On 27/08/2012 22:37, Filip Hanik (mailing lists) wrote:
> >>>> -----Original Message-----
> >>>> From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
> >>>> Sent: Monday, August 27, 2012 2:09 PM
> >>>> To: Tomcat Developers List
> >>>> Subject: Re: svn commit: r1377689 -
> >>>>
> >>
> /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListe
> >>>> ner.java
> >>>>
> >>>> 2012/8/27 Mark Thomas <ma...@apache.org>:
> >>>>> On 27/08/2012 15:20, fha...@apache.org wrote:
> >>>>>> Author: fhanik
> >>>>>> Date: Mon Aug 27 14:20:55 2012
> >>>>>> New Revision: 1377689
> >>>>>>
> >>>>>> URL: http://svn.apache.org/viewvc?rev=1377689&view=rev
> >>>>>> Log:
> >>>>>> Per http://markmail.org/message/nqnogctvfuyzhtol
> >>>>>>
> >>>>>> 1. Already encountered two users that would like to set this
> value.
> >>>> There is
> >>>>>> never any need to hard code any value, regardless of its use
> >>>>>
> >>>>> What is the use case for wanting to set this value? I can
> understand
> >>>>> users not liking the previous value that triggered a full GC every
> >>>> hour
> >>>>> and wanting to change that but I fail to see why anyone would want
> >> to
> >>>>> change this now it is set to trigger a full GC every 290 million
> >> years
> >>>>> or so.
> >>
> >>>> Maybe somebody wants their full GC once an hour, or once a day?
> >>
> >> That is not what this listener is for. The listener's purpose is to
> >> prevent memory leaks, not provide options that allow users to tinker
> >> with internal JVM GC settings.
> >>
> >> I have yet to see a valid use case for this new attribute.
> > [Filip Hanik]
> > The use case is very much valid, as if they had previously called that
> > method, your code will override it.
> > So in effect, you're hard coding the GC interval, but not letting a
> user
> > control it.
>
> Nope. You should have looked at the implementation of
> sun.misc.GC#requestLatency(long) rather than assuming how it worked.
>
> > It's not tomcat's role to configure GC intervals. It may be that
> tomcat
> > somehow initiated the GC interval, and if that is the case, it must
> expose
> > the actual interval to the user. Tomcat should not change JVM settings
> > without letting the user configure them,
>
> Tomcat setting this value has zero impact on any user code or JRE code
> that sets a lower value either before Tomcat sets it or after.
>
> I still see no valid use case for this attribute and without a valid use
> case my veto remains.
[Filip Hanik]
Now you're just being stubborn. It would be like me going back and vetoing
the hard coded value, and we'd run around in circles like little chickens.
The reason I think the veto is unreasonable is that there is no
functionality removed with this. There is nothing to be lost.
IIRC any call changes the value, since there is only one daemon thread
created. And since gcDaemonProtection is true by default means that 99.9% of
tomcat instances will have this daemon thread running. Since we have this
thread running, then we might as well hand out the ability to the users.
Since you are turning this thread on, give them the ability to change the
interval at which it is running.
141 } else {
142 /* Notify the existing daemon thread
143 * that the lateency target has changed
144 */
145 lock.notify();
146 }
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
