Michael André Pearce created CXF-4313:
-----------------------------------------
Summary: 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
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 jdk5
>+ it by default is the same value) and it is well documented for developers
>who want to tweek their application 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
