tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: svn commit: r1377689 - /tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
Date Mon, 27 Aug 2012 22:08:42 GMT
2012/8/28 Mark Thomas <markt@apache.org>:
> On 27/08/2012 22:48, Filip Hanik (mailing lists) wrote:
>>
>>
>>> -----Original Message-----
>>> From: Mark Thomas [mailto:markt@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.kolinko@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 <markt@apache.org>:
>>>>>> On 27/08/2012 15:20, fhanik@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message