2012/8/28 Mark Thomas <ma...@apache.org>: > 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. >
Agreed. When a user wants to configure this value by themselves, they should just disable this feature in Tomcat with gcDaemonProtection="false". ( >> I took care of that an hour ago. >> http://svn.apache.org/viewvc?rev=1377831&view=rev > [Filip Hanik] > Got it, what's the point of the following code change? > - method.invoke(null, getGcDaemonPeriod()); > + method.invoke(null, > Long.valueOf(getGcDaemonPeriod())); There was implicit boxing operation, which gives a warning with our Eclipse settings (the ones in res/ide-support/eclipse/java-compiler-errors-warnings.txt ) ) Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
