On 28/08/2012 00:16, Filip Hanik (mailing lists) wrote: >> -----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.
No, I am being consistent. I am against unnecessary bloat. > 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. It doesn't add anything either. It is pointless bloat. > IIRC any call changes the value, since there is only one daemon thread > created. Then again, I suggest you actually go and look at the source code and you'd see that you are wrong. 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. Again, provide a valid use case for this option and I'll support the change. You have yet to do so. My veto stands. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
