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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
