[
https://issues.apache.org/jira/browse/CXF-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-4313.
------------------------------
Resolution: Fixed
Fix Version/s: 2.3.11
2.4.8
2.5.4
2.6.1
Assignee: Daniel Kulp
Added some flags/hooks in there to be able to turn off each hack (or turn off
all of them).
> Hourly GC Caused by Framework - Unable to GC tune application if using
> framework.
> ---------------------------------------------------------------------------------
>
> Key: CXF-4313
> URL: https://issues.apache.org/jira/browse/CXF-4313
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.5
> Reporter: Michael André Pearce
> Assignee: Daniel Kulp
> Fix For: 2.6.1, 2.5.4, 2.4.8, 2.3.11
>
>
> After looking into why our application GC tuning wasn't working/taking any
> effect and full gc continued to occur every hour, and saw from the GC logs
> that System.GC was being called, traced it down to our use of CXF framework,
> where we are using it for HTTP WS-SOAP Service calls.
> Seems that the following is being set code-ally by the JDKBugHacks, looking
> through the code history seems this got added on the 28th Feb 2011.
> From the comments it seems this has been added due to RMI. Not 100% sure why
> you're wanting to codally override RMI setting this up (especially as in jdk
> 6 + it by default is the same value 1 hour) and it is well documented for
> developers who want to tweek their application (especially if they're on
> earlier java versions) with regards to GC how to change this setting using
> the following two jvm switches to change the interval anyhow.
>
> -Dsun.rmi.dgc.server.gcInterval
> -Dsun.rmi.dgc.client.gcInterval
> And can actually turn off completely by setting it to 0x7ffffffffffffffe but
> that is by the by.
> The issues i have is that as a user of the framework,
> a) i am unable to turn off the hard coding by any feature flag, and this
> affects my gc turning of my application.
> b) If a user is using CXF with no RMI why set this up? Only setup if using
> RMI if it is really need so that it doesnt effect users of the framework
> using it for http service calls.
> I take it that these "hacks" are influenced heavily from tomcat, but this is
> because of its servlet hot deployable class loading features. Even so for
> that tomcat do allow two options to disable this feature if you wish, i.e. u
> don't want hot deploy to tomcat thus not worried about this leak prevention
> with the class loader and you want to fine tune your applications gc for the
> applications requirements and SLA. They provide the following nice features:
> Configure to not add the gcDaemonProtection
> <Listener
> className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
> gcDaemonProtection="false"/>
> And the ability to Disable the listener altogether
> Code in question in the JDKBugHacks class.
> // Several components end up calling:
> // sun.misc.GC.requestLatency(long)
> //
> // Those libraries / components known to trigger memory leaks
> due to
> // eventual calls to requestLatency(long) are:
> // - javax.management.remote.rmi.RMIConnectorServer.start()
> try {
> Class<?> clazz = Class.forName("sun.misc.GC");
> Method method = clazz.getDeclaredMethod("requestLatency",
> new Class[] {Long.TYPE});
> method.invoke(null, Long.valueOf(3600000));
> } catch (Throwable e) {
> //ignore
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
