Re: Is this a classloader leak?
On 20/09/18 17:25, Suvendu Sekhar Mondal wrote: > Hello Everyone, > > Recently I am investigating a Metaspace leak issue. I dumped Metaspace > content over time using jcmd. While comparing them I can see that > there are 15,000 classes which are taking 120MB in that area! For all > of them InstCount(number of object instances of the Java class) is > zero. That tells me there is *no object* for those 15K classes in > heap. I can see that too in heap. No objects found for those classes. > > Then why are they still live in the Metaspace and not getting cleared > by Full GC? Definitely they have some reference(s) from somewhere. All > I can see that they were loaded by 'class loader 0x21005760a > 'org/apache/catalina/loader/WebappClassLoader'. Is this another form > of classloader leak or something else? Any idea? Use a profiler, trace the GC roots and figure out why the references are being retained. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Is this a classloader leak?
Hello Everyone, Recently I am investigating a Metaspace leak issue. I dumped Metaspace content over time using jcmd. While comparing them I can see that there are 15,000 classes which are taking 120MB in that area! For all of them InstCount(number of object instances of the Java class) is zero. That tells me there is *no object* for those 15K classes in heap. I can see that too in heap. No objects found for those classes. Then why are they still live in the Metaspace and not getting cleared by Full GC? Definitely they have some reference(s) from somewhere. All I can see that they were loaded by 'class loader 0x21005760a 'org/apache/catalina/loader/WebappClassLoader'. Is this another form of classloader leak or something else? Any idea? Environment: Windows 2012 server, JDK 1.8_92, Tomcat 7.0.55 Thanks! Suvendu - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 classloader leak in Commons Pool
Sorry, you are right, it is in org.apache.tomcat.util.modeler.BaseModelMBean, and resource attribute it is retaining is an org.apache.commons.dbcp.BasicDataSource Diego Caldarale, Charles R escribió: From: Diego Rodríguez Martín [mailto:[EMAIL PROTECTED] Subject: Re: Tomcat 6 classloader leak in Commons Pool I have found that the offending class causing the leak is org.apache.tomcat.util.modeler.ManagedBean. It keeps two attributes referencing my dbcp pool, called resource and resourceType. Are you sure about that class name? It looks like the fields you've mentioned are actually in: org.apache.tomcat.util.modeler.BaseModelMBean The resourceType field is a String, so that isn't actually a reference to your DBCP pool, but resource is just an Object, so that's probably the real culprit. There does not appear to be any way to clear the resource field in a BaseModelMBean, and I don't yet know where references to the BaseModelMBean are maintained. What exactly does the resource field reference? A connection, the DBCP factory, or ??? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Diego Rodríguez Martín ([EMAIL PROTECTED]) ALTIRIA TIC - Servicios SMS - Desarrollo Web Tel. +34 913311198 - Fax +34 913310087 - Móvil +34 610299750 www.altiria.com -
Re: Tomcat 6 classloader leak in Commons Pool
Hi, I have tried what you suggested but it doesn't release the context properly. The method in Registry is unregisterComponent (unregister doesn't exist) ObjectName on = new ObjectName(Catalina:type=DataSource,path=/myapp,host=localhost,class=org.apache.commons.dbcp.BasicDataSource,name=jdbc/MyPool); (Registry.getRegistry(null, null)).unregisterComponent(on); I have tried with other parameters in ObjectName, but it doesn't complain even if the parameters are wrong so, how can I know they are right? Bill, How do I open a BZ issue? Thank you very much for your help Diego Bill Barker escribió: Diego Rodríguez Martín [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, I have been making some more tests about this issue, using old dbcp/pool factory to get rid of the memory leaks of tomcat embedded libraries commons-pool/commons-dbcp When using my own factory for dbcp and commons pool (the old versions), I clear the resources used invoking datasource.close() in my servlet destroy method. With a memory profiler, I have found that the offending class causing the leak is org.apache.tomcat.util.modeler.ManagedBean. It keeps two attributes referencing my dbcp pool, called resource and resourceType. Is there a way I can access from my servlet this class (org.apache.tomcat.util.modeler.ManagedBean) in order to clean the references? Is there any other action to be taken to free a resource than calling datasource.close() that I am missing? Is my fault freeing the resource or its Tomcat fault? It is probably Tomcat's fault, since it looks like Tomcat doesn't unregister the DataSource elements from JMX when the context is stopped. You should probably open a BZ issue for this (it doesn't look like the fix is too hard, NamingContextListener just needs to handle a stop event). To work around it, you just need to unregister the MBean, so something like: ObjectName on = new ObjectName(Catalina:type=DataSource,path=/myapp,host=localhost,class=my.full.class.name,name=resourceName); Registry.getRegistry(null, null).unregister(on); should work. Thank you very much in advance for your help Diego Diego Rodríguez Martín escribió: Hi, I have found what you said about the factory. It is ported to 6.0. I have tried to use the old commons-dbcp library, copying commons-pool-1.2.jar and commons-dbcp-1.2.2.jar in tomcat lib directory and defining the attribute factory=org.apache.commons.dbcp.BasicDataSourceFactory in the resource in my context.xml. It works, but I still have a memory leak. Tomcat is retaining my new commons-dbcp classes, and I think it is related to this classes: org.apache.tomcat.util.modeler.BaseModelMBean, com.sun.jmx.mbeanserver.NamedObject, com.sun.jmx.mbeanserver.RepositorySupport. com.sun.jmx.interceptor.DefaultMBeanServerInterceptor com.sun.jmx.mbeanserver.JmxMBeanServer, This part of Tomcat is completely unkown to me, Do you have any clue? Many thanks for your help Diego David Smith escribió: In older versions of tomcat (5.0.x) there is a factory attribute defining the pool to use. It's unclear from the limited look I did whether that was carried forward to 5.5 and 6.0. --David Diego Rodríguez Martín wrote: Hi, Is there any way to fix this leak downgrading the version of commons pool. I have a production enviroment where we have a lot of deploy/undeploy and with this leak we have to stop/start Tomcat very often. Is there a possibility of replacing tomcat-dbcp.jar with the older individual jars? It will work or you have used new functionalities of these packages? Thanks Diego Rémy Maucherat escribió: On 6/8/07, Diego Rodríguez Martín [EMAIL PROTECTED] wrote: It affects version 1.3 of commons pool. In tomcat 6, commons pool is embbeded in /tomcat-dbcp.jar/, and the docs don't say with version of commons is inside. It's that version. A new commons-pool version will be integrated when it's available. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Diego Rodríguez Martín ([EMAIL PROTECTED]) ALTIRIA TIC - Servicios SMS - Desarrollo Web Tel. +34 913311198 - Fax +34 913310087 - Móvil +34 610299750 www.altiria.com - - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
Re: Tomcat 6 classloader leak in Commons Pool
Hi, I have been making some more tests about this issue, using old dbcp/pool factory to get rid of the memory leaks of tomcat embedded libraries commons-pool/commons-dbcp When using my own factory for dbcp and commons pool (the old versions), I clear the resources used invoking datasource.close() in my servlet destroy method. With a memory profiler, I have found that the offending class causing the leak is org.apache.tomcat.util.modeler.ManagedBean. It keeps two attributes referencing my dbcp pool, called resource and resourceType. Is there a way I can access from my servlet this class (org.apache.tomcat.util.modeler.ManagedBean) in order to clean the references? Is there any other action to be taken to free a resource than calling datasource.close() that I am missing? Is my fault freeing the resource or its Tomcat fault? Thank you very much in advance for your help Diego Diego Rodríguez Martín escribió: Hi, I have found what you said about the factory. It is ported to 6.0. I have tried to use the old commons-dbcp library, copying commons-pool-1.2.jar and commons-dbcp-1.2.2.jar in tomcat lib directory and defining the attribute factory=org.apache.commons.dbcp.BasicDataSourceFactory in the resource in my context.xml. It works, but I still have a memory leak. Tomcat is retaining my new commons-dbcp classes, and I think it is related to this classes: org.apache.tomcat.util.modeler.BaseModelMBean, com.sun.jmx.mbeanserver.NamedObject, com.sun.jmx.mbeanserver.RepositorySupport. com.sun.jmx.interceptor.DefaultMBeanServerInterceptor com.sun.jmx.mbeanserver.JmxMBeanServer, This part of Tomcat is completely unkown to me, Do you have any clue? Many thanks for your help Diego David Smith escribió: In older versions of tomcat (5.0.x) there is a factory attribute defining the pool to use. It's unclear from the limited look I did whether that was carried forward to 5.5 and 6.0. --David Diego Rodríguez Martín wrote: Hi, Is there any way to fix this leak downgrading the version of commons pool. I have a production enviroment where we have a lot of deploy/undeploy and with this leak we have to stop/start Tomcat very often. Is there a possibility of replacing tomcat-dbcp.jar with the older individual jars? It will work or you have used new functionalities of these packages? Thanks Diego Rémy Maucherat escribió: On 6/8/07, Diego Rodríguez Martín [EMAIL PROTECTED] wrote: It affects version 1.3 of commons pool. In tomcat 6, commons pool is embbeded in /tomcat-dbcp.jar/, and the docs don't say with version of commons is inside. It's that version. A new commons-pool version will be integrated when it's available. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Diego Rodríguez Martín ([EMAIL PROTECTED]) ALTIRIA TIC - Servicios SMS - Desarrollo Web Tel. +34 913311198 - Fax +34 913310087 - Móvil +34 610299750 www.altiria.com - - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 6 classloader leak in Commons Pool
From: Diego Rodríguez Martín [mailto:[EMAIL PROTECTED] Subject: Re: Tomcat 6 classloader leak in Commons Pool I have found that the offending class causing the leak is org.apache.tomcat.util.modeler.ManagedBean. It keeps two attributes referencing my dbcp pool, called resource and resourceType. Are you sure about that class name? It looks like the fields you've mentioned are actually in: org.apache.tomcat.util.modeler.BaseModelMBean The resourceType field is a String, so that isn't actually a reference to your DBCP pool, but resource is just an Object, so that's probably the real culprit. There does not appear to be any way to clear the resource field in a BaseModelMBean, and I don't yet know where references to the BaseModelMBean are maintained. What exactly does the resource field reference? A connection, the DBCP factory, or ??? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 classloader leak in Commons Pool
Diego Rodríguez Martín [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, I have been making some more tests about this issue, using old dbcp/pool factory to get rid of the memory leaks of tomcat embedded libraries commons-pool/commons-dbcp When using my own factory for dbcp and commons pool (the old versions), I clear the resources used invoking datasource.close() in my servlet destroy method. With a memory profiler, I have found that the offending class causing the leak is org.apache.tomcat.util.modeler.ManagedBean. It keeps two attributes referencing my dbcp pool, called resource and resourceType. Is there a way I can access from my servlet this class (org.apache.tomcat.util.modeler.ManagedBean) in order to clean the references? Is there any other action to be taken to free a resource than calling datasource.close() that I am missing? Is my fault freeing the resource or its Tomcat fault? It is probably Tomcat's fault, since it looks like Tomcat doesn't unregister the DataSource elements from JMX when the context is stopped. You should probably open a BZ issue for this (it doesn't look like the fix is too hard, NamingContextListener just needs to handle a stop event). To work around it, you just need to unregister the MBean, so something like: ObjectName on = new ObjectName(Catalina:type=DataSource,path=/myapp,host=localhost,class=my.full.class.name,name=resourceName); Registry.getRegistry(null, null).unregister(on); should work. Thank you very much in advance for your help Diego Diego Rodríguez Martín escribió: Hi, I have found what you said about the factory. It is ported to 6.0. I have tried to use the old commons-dbcp library, copying commons-pool-1.2.jar and commons-dbcp-1.2.2.jar in tomcat lib directory and defining the attribute factory=org.apache.commons.dbcp.BasicDataSourceFactory in the resource in my context.xml. It works, but I still have a memory leak. Tomcat is retaining my new commons-dbcp classes, and I think it is related to this classes: org.apache.tomcat.util.modeler.BaseModelMBean, com.sun.jmx.mbeanserver.NamedObject, com.sun.jmx.mbeanserver.RepositorySupport. com.sun.jmx.interceptor.DefaultMBeanServerInterceptor com.sun.jmx.mbeanserver.JmxMBeanServer, This part of Tomcat is completely unkown to me, Do you have any clue? Many thanks for your help Diego David Smith escribió: In older versions of tomcat (5.0.x) there is a factory attribute defining the pool to use. It's unclear from the limited look I did whether that was carried forward to 5.5 and 6.0. --David Diego Rodríguez Martín wrote: Hi, Is there any way to fix this leak downgrading the version of commons pool. I have a production enviroment where we have a lot of deploy/undeploy and with this leak we have to stop/start Tomcat very often. Is there a possibility of replacing tomcat-dbcp.jar with the older individual jars? It will work or you have used new functionalities of these packages? Thanks Diego Rémy Maucherat escribió: On 6/8/07, Diego Rodríguez Martín [EMAIL PROTECTED] wrote: It affects version 1.3 of commons pool. In tomcat 6, commons pool is embbeded in /tomcat-dbcp.jar/, and the docs don't say with version of commons is inside. It's that version. A new commons-pool version will be integrated when it's available. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Diego Rodríguez Martín ([EMAIL PROTECTED]) ALTIRIA TIC - Servicios SMS - Desarrollo Web Tel. +34 913311198 - Fax +34 913310087 - Móvil +34 610299750 www.altiria.com - - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 classloader leak in Commons Pool
Hi, I have found what you said about the factory. It is ported to 6.0. I have tried to use the old commons-dbcp library, copying commons-pool-1.2.jar and commons-dbcp-1.2.2.jar in tomcat lib directory and defining the attribute factory=org.apache.commons.dbcp.BasicDataSourceFactory in the resource in my context.xml. It works, but I still have a memory leak. Tomcat is retaining my new commons-dbcp classes, and I think it is related to this classes: org.apache.tomcat.util.modeler.BaseModelMBean, com.sun.jmx.mbeanserver.NamedObject, com.sun.jmx.mbeanserver.RepositorySupport. com.sun.jmx.interceptor.DefaultMBeanServerInterceptor com.sun.jmx.mbeanserver.JmxMBeanServer, This part of Tomcat is completely unkown to me, Do you have any clue? Many thanks for your help Diego David Smith escribió: In older versions of tomcat (5.0.x) there is a factory attribute defining the pool to use. It's unclear from the limited look I did whether that was carried forward to 5.5 and 6.0. --David Diego Rodríguez Martín wrote: Hi, Is there any way to fix this leak downgrading the version of commons pool. I have a production enviroment where we have a lot of deploy/undeploy and with this leak we have to stop/start Tomcat very often. Is there a possibility of replacing tomcat-dbcp.jar with the older individual jars? It will work or you have used new functionalities of these packages? Thanks Diego Rémy Maucherat escribió: On 6/8/07, Diego Rodríguez Martín [EMAIL PROTECTED] wrote: It affects version 1.3 of commons pool. In tomcat 6, commons pool is embbeded in /tomcat-dbcp.jar/, and the docs don't say with version of commons is inside. It's that version. A new commons-pool version will be integrated when it's available. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Diego Rodríguez Martín ([EMAIL PROTECTED]) ALTIRIA TIC - Servicios SMS - Desarrollo Web Tel. +34 913311198 - Fax +34 913310087 - Móvil +34 610299750 www.altiria.com - - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 classloader leak in Commons Pool
Hi, Is there any way to fix this leak downgrading the version of commons pool. I have a production enviroment where we have a lot of deploy/undeploy and with this leak we have to stop/start Tomcat very often. Is there a possibility of replacing tomcat-dbcp.jar with the older individual jars? It will work or you have used new functionalities of these packages? Thanks Diego Rémy Maucherat escribió: On 6/8/07, Diego Rodríguez Martín [EMAIL PROTECTED] wrote: It affects version 1.3 of commons pool. In tomcat 6, commons pool is embbeded in /tomcat-dbcp.jar/, and the docs don't say with version of commons is inside. It's that version. A new commons-pool version will be integrated when it's available. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Diego Rodríguez Martín ([EMAIL PROTECTED]) ALTIRIA TIC - Servicios SMS - Desarrollo Web Tel. +34 913311198 - Fax +34 913310087 - Móvil +34 610299750 www.altiria.com - - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 classloader leak in Commons Pool
In older versions of tomcat (5.0.x) there is a factory attribute defining the pool to use. It's unclear from the limited look I did whether that was carried forward to 5.5 and 6.0. --David Diego Rodríguez Martín wrote: Hi, Is there any way to fix this leak downgrading the version of commons pool. I have a production enviroment where we have a lot of deploy/undeploy and with this leak we have to stop/start Tomcat very often. Is there a possibility of replacing tomcat-dbcp.jar with the older individual jars? It will work or you have used new functionalities of these packages? Thanks Diego Rémy Maucherat escribió: On 6/8/07, Diego Rodríguez Martín [EMAIL PROTECTED] wrote: It affects version 1.3 of commons pool. In tomcat 6, commons pool is embbeded in /tomcat-dbcp.jar/, and the docs don't say with version of commons is inside. It's that version. A new commons-pool version will be integrated when it's available. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 classloader leak in Commons Pool
On 6/8/07, Diego Rodríguez Martín [EMAIL PROTECTED] wrote: It affects version 1.3 of commons pool. In tomcat 6, commons pool is embbeded in /tomcat-dbcp.jar/, and the docs don't say with version of commons is inside. It's that version. A new commons-pool version will be integrated when it's available. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
