Re: Manager undeploy task only stops webapp
Hi, I've found the problem. As you said, it was a problem of configuration. I defined the docbase and also was using localwar parameter in ant task with the same dir as docbase. Removing the localwar parameter in ant task solved the problem Many thanks Diego Caldarale, Charles R escribió: From: Diego Rodríguez Martín [mailto:[EMAIL PROTECTED] Subject: Re: Manager undeploy task only stops webapp I'm still investigating this issue. Same behaviour if I use manager directly through the interface instead of using ant task. Undeployment via the manager webapp in 6.0.16 works fine for me. Is the webapp you're trying to manipulate configured incorrectly, by any chance? Things that were errors but largely ignored in 4.1 may have different side effects in 5.5 and 6.0 (e.g., having an app with docBase == appBase, or invalidly specifying a path attribute in a Context element). - 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 www.programacionenjava.com -
Re: Manager undeploy task only stops webapp
) at java.net.ServerSocket.implAccept(ServerSocket.java:450) at java.net.ServerSocket.accept(ServerSocket.java:421) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:61) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:310) at java.lang.Thread.run(Thread.java:595) ContainerBackgroundProcessor[StandardEngine[Catalina]] daemon prio=6 tid=0x0af2ff80 nid=0xf3c waiting on condition [0x0b50f000..0x0b50f9e8] at java.lang.Thread.sleep(Native Method) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1579) at java.lang.Thread.run(Thread.java:595) Low Memory Detector daemon prio=6 tid=0x0096dbf8 nid=0x264 runnable [0x..0x] CompilerThread0 daemon prio=10 tid=0x0096c888 nid=0xa78 waiting on condition [0x..0x0abff848] Signal Dispatcher daemon prio=10 tid=0x0096bc08 nid=0xd38 waiting on condition [0x..0x] Finalizer daemon prio=8 tid=0x00962c28 nid=0xb58 in Object.wait() [0x0ab7f000..0x0ab7fc68] at java.lang.Object.wait(Native Method) - waiting on 0x02f1bfb0 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked 0x02f1bfb0 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) Reference Handler daemon prio=10 tid=0x009617b8 nid=0x578 in Object.wait() [0x0ab3f000..0x0ab3fce8] at java.lang.Object.wait(Native Method) - waiting on 0x02f1c030 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked 0x02f1c030 (a java.lang.ref.Reference$Lock) main prio=6 tid=0x000377a8 nid=0x8c8 runnable [0x0007f000..0x0007fc3c] at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) - locked 0x0335bef0 (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:450) at java.net.ServerSocket.accept(ServerSocket.java:421) at org.apache.catalina.core.StandardServer.await(StandardServer.java:389) at org.apache.catalina.startup.Catalina.await(Catalina.java:642) at org.apache.catalina.startup.Catalina.start(Catalina.java:602) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) VM Thread prio=10 tid=0x0095ed08 nid=0xcec runnable VM Periodic Task Thread prio=10 tid=0x0096ef80 nid=0xd70 waiting on condition Diego Rodríguez Martín escribió: Hi, I'm using manager in Tomcat 6.0.16 throught ant task (1.6.5) to undeploy webapps. I have copied the new catalina-ant.jar in ANT_HOME/lib directory. The problem is that now the application is stopped instead of undeployed though the output message is undeployed app at context /xx. I then use list task and my webapp is in status stopped. If I execute again the undeploy task, the output message is again undeployed app at context /xx but this time the webapp is undeployed and not listed anymore. It seems like the task is undeploying in two steps. I have been using the undeploy task since 4.1.27 version and the task never behaved that way. I have search the docs and there is no info about any change in 6.0.16 (6.0.14 is ok) Are there any undocumented changes in 6.0.16 or is it a malfunction? -- - Diego Rodríguez Martín ([EMAIL PROTECTED]) ALTIRIA TIC - Servicios SMS - Desarrollo Web Tel. +34 913311198 - Fax +34 915713993 - 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]
Manager undeploy task only stops webapp
Hi, I'm using manager in Tomcat 6.0.16 throught ant task (1.6.5) to undeploy webapps. I have copied the new catalina-ant.jar in ANT_HOME/lib directory. The problem is that now the application is stopped instead of undeployed though the output message is undeployed app at context /xx. I then use list task and my webapp is in status stopped. If I execute again the undeploy task, the output message is again undeployed app at context /xx but this time the webapp is undeployed and not listed anymore. It seems like the task is undeploying in two steps. I have been using the undeploy task since 4.1.27 version and the task never behaved that way. I have search the docs and there is no info about any change in 6.0.16 (6.0.14 is ok) Are there any undocumented changes in 6.0.16 or is it a malfunction? -- - Diego Rodríguez Martín ALTIRIA TIC - Servicios SMS - Desarrollo Web Tel. +34 913311198 - Fax +34 915713993 - 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]
Cleanup of org.apache.naming.resources.CacheEntry resources
Hi, I am memory profiling a webapp for my company because we suspect it has memory leaks when redeploying. This webapp has to be redeployed several times a week for security reasons (most of the time it is undeployed) and the memory leaks forced us to shutdown tomcat once a week to avoid OOM exception. I'm using jvm1.5 and tomcat 6.0.13 (also tried with 6.0.14 and today with 6.0.16), and Yourkit as the profiling tool. I have made the test in both linux and windows. I have created a JMeter test to deploy the app using the manager, make some request to the app and then undeploy it using again the manager app in a loop. After some redeployments, I got my OutOfMemoryException. Then I checked with my profiling tool and found that my own classes were correctly destroyed, and the classes retaining more memory were these ones (listed as a heirarchy): org.apache.catalina.core.ApplicationContext$DispatchData org.apache.catalina.core.ApplicationContext mapper of org.apache.catalina.core.StandardContext context of org.apache.tomcat.util.http.mapper.Mapper resources of org.apache.tomcat.util.http.mapper.Mapper$Context cache of org.apache.naming.resources.ProxyDirContext cache of org.apache.naming.resources.ResourceCache org.apache.naming.resources.CacheEntry[] The number of objects of each class were exactly the number of times I had redeployed the webapp. I have checked the contents of CacheEntry inside CacheEntry[] and it has an attribute name and the contents are the jsps and tld files of my app. There are as many CacheEntry with the same jsp attribute as times the webapp has been reloaded. I have made a simple webapp with 2 jsp and a taglibrary, and the memory leak is still there, so I guess there is no cleaning of CacheEntry resources at context shutdown. Have I found a memory leak in Tomcat? Is my explanation correct or I have missed the leak source? Should I open a BZ issue? Is there any workaround to clean this resources on context shutdown? -- - Diego Rodríguez Martín ALTIRIA TIC - Servicios SMS - Desarrollo Web Tel. +34 913311198 - Fax +34 915713993 - 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: What do I do with a heap dump? (OOM Permgen)
Hi, I found a memory leak in commons pool version 1.3 that is affecting tomcat 6.0.x as it is the commons pool library embedded in it. I tried a workaround using a factory with commons 1.2, but it also showed a memory leak. http://www.mail-archive.com/users@tomcat.apache.org/msg29820.html As far as I know, it has not been resolved, so you could be running into this Diego Greg Vilardi escribió: On 2 Nov 2007 at 7:24, Caldarale, Charles R wrote: From: Peter Crowther [mailto:[EMAIL PROTECTED] Subject: RE: What do I do with a heap dump? (OOM Permgen) As far as I know, public enemy #1 for eating PermGen space is still developers using the Singleton pattern in their code and not having listeners to null out the singleton instance when the webapp is undeployed. Analagous use of ThreadLocal is also a subtle contributor to the problem. The offending references must be cleared at the end of processing of each request, since listeners don't have ready access to the thread pool. Thank you for the pointers Peter. We do not have any Singletons in the application nor do we use ThreadLocal. However, we do not seem to be cleaning up the JDBC classes on redeploy. I'll install the SessionListener code that is mentionned in the references in Peter's reply. I'm also using the eval version of yourkit now to see what exactly is attached to each of the 52 WebAppClassLoaders in the dump. I'll be back if I get stuck again further down the road. Thank you to all of the people who replied for the pointers and the tool recommendations. -Greg -- - Diego Rodríguez Martín ([EMAIL PROTECTED]) ALTIRIA TIC - Servicios SMS - Desarrollo Web Tel. +34 913311198 - Fax +34 915713993 - Móvil +34 610299750 www.altiria.com -
Re: Tomcat 6 and Permgen increase with redeployments
Hi, There is a leak in commons pool in version 6 that prevents WebappClassLoader from being garbage collected http://www.mail-archive.com/users@tomcat.apache.org/msg29820.html Anyway, you may be encountering memory leaks of you own, and nothing can replace memory profiling to find your offending classes. This link may be an introduction to memory leaks, http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 Diego wild_oscar escribió: Although I've read a lot in the past week about Permgen and the problems of some libs, I haven't been able to find a solution to my problem. I'm running Tomcat 6 and an application with (among others): - Struts 2 - Hibernate - Tiles 2 - Log4j - ant Redeployment with ant (or the tomcat manager) makes the permgen space grow and it doesn't shrink. I'm using Jprofiler to figure out what's wrong. I recorded allocation data, deployed the application, stopped recording and undeployed. I made GC collect, well, the garbage, and Permgen free space did not increase. I seem to be stuck with a lot of log4j classes and hibernate classes. I've pushed the Postgresql driver to the container's /lib. I've also tried pushing log4j and commons-logging there as well. Waiting some time does not solve the problem as well. Permgen space will not decrease. As for hibernate, I've implemented a static SessionFactory, which I close in the destroy() method of my servletcontextlistener. Can anyone pinpoint the probable cause, solution or way to tackle this problem? Increasing the size of the Permgen only postpones the problem: at the end of a workday it'll be full, after a dozen redeployments... - 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
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, e
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]
Tomcat and commons logging
Hi, I have some problems using commons logging with log4j and tomcat, related to classloading. After some google searching, I have come to this article by one of the log4j experts http://www.qos.ch/logging/classloader.jsp In this article, it is explained how commons-logging (1.0.3) can lead to some classloading problems. There is a solution at the end of the article, but for Tomcat 5.0.x. I'm using Tomcat 6.0.13, configured to use log4j as it is explained in the docs (http://tomcat.apache.org/tomcat-6.0-doc/logging.html) and I have this problem. My questions is: The article says that I have to use version 1.0.4 or later but I haven't found which version it is used by Tomcat, which version of commons-logging is built in the extras in Tomcat 6? -- - 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, 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]
Tomcat 6 classloader leak in Commons Pool
Hi, I have a webapp that is running ok under tomcat 5.5. I have upgrade to Tomcat 6 and I have found a big memory leak because WebAppClassLoader gets never garbage collected. I have used a profiler and have found that the object that is stopping the garbage collector could be EVICTION_TIMER of org.apache.tomcat.dbcp.pool.impl.GenericObjectPool. I have googled it and I have found the following bug in commons pool https://issues.apache.org/jira/browse/POOL-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484747 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. Could tomcat be running with this bug? Since pool is embedded, is there a simple workaround to get rid of it downgrading commons pool version to use the same as tomcat 5.5? Thanks -- - 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: Max number of contexts
Hi again, I have been evaluating the architecture described below (one kernel with lightweight webapps registered by ContextListener), but I'm still worried about memory. You said that memory will be the main limitation, but what I would like to know is how many memory overhead produces a context compared to the webapp plain classes it loads. We're planning to have hundreds of contexts and I would like to know if we should consider another architecture for our problem. In this new project we will use Tomcat 5.5, but we are using now Tomcat 4.1 for other project and we are having OutOf Memory errors every week, more frecuently as the number of contexts incresases (between10-15 contexts aprox), so you can understand my worries Thanks again Diego Filip Hanik - Dev Lists escribió: Diego Rodriguez wrote: Hi, I'm using Tomcat 5.5.20. In the docs says You may define as many *Context* elements as you wish I'm going to design a new web application that will act as a kernel for other lightweight webapps that will implement different services and may be hot installed at any time. My plan is implement these services (lightweight webapps) as contexts that will register in the kernel using a ContextListener. What I would like to know is if there is any real maximum or a performance penalty if I reach some limit. Is there anybody who has implemented an architecture like this? ] Memory will be your main limitation. Filip Thanks in advance Diego No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.11/721 - Release Date: 3/13/2007 4:51 PM - 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]
