cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael André Pearce (JIRA) <j...@apache.org>
Subject [jira] [Updated] (CXF-4313) Hourly GC Caused by Framework - Unable to GC tune application if using framework.
Date Fri, 11 May 2012 18:44:48 GMT

     [ 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

       

Mime
View raw message