You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Michael André Pearce (JIRA)" <ji...@apache.org> on 2012/05/11 20:38:49 UTC
[jira] [Created] (CXF-4313) Hourly GC Caused by Framework - Unable
to GC tune application if using framework.
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
[jira] [Resolved] (CXF-4313) Hourly GC Caused by Framework - Unable
to GC tune application if using framework.
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (CXF-4313) Hourly GC Caused by Framework - Unable
to GC tune application if using framework.
Posted by "Michael André Pearce (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael André Pearce updated CXF-4313:
--------------------------------------
Description:
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
}
was:
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
}
> 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 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