Re: [JDBC Pool] PoolCleaner creates some sort of memory
I'll take a look at the test failures, but yes you can ignore them. Tomcat 7.0.27 will have the fix included, about to be released shortly building it is easy, builds with both maven and ant Filip - Original Message - From: Michael Osipov michael.osi...@siemens.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, March 30, 2012 2:05:50 AM Subject: RE: [JDBC Pool] PoolCleaner creates some sort of memory Konstantin Kolinko wrote: 2012/3/30 Osipov, Michael michael.osi...@siemens.com: Filip Hanik (mailing lists) wrote: http://svn.apache.org/viewvc?view=revisionrevision=1306946 Thanks for the patch, I am having trouble to build from source. I do have some test failures, should I ignore them and go on? Please be more specific. In what tests? Have a look at this: http://pastebin.com/kiHLF6D9 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [JDBC Pool] PoolCleaner creates some sort of memory
Filip Hanik (mailing lists) wrote: http://svn.apache.org/viewvc?view=revisionrevision=1306946 Thanks for the patch, I am having trouble to build from source. I do have some test failures, should I ignore them and go on? Another one, can we have a clearer name for the thread, e.g. like the I have suggested in a previous mail? Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [JDBC Pool] PoolCleaner creates some sort of memory
2012/3/30 Osipov, Michael michael.osi...@siemens.com: Filip Hanik (mailing lists) wrote: http://svn.apache.org/viewvc?view=revisionrevision=1306946 Thanks for the patch, I am having trouble to build from source. I do have some test failures, should I ignore them and go on? Please be more specific. In what tests? Another one, can we have a clearer name for the thread, e.g. like the I have suggested in a previous mail? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [JDBC Pool] PoolCleaner creates some sort of memory
Konstantin Kolinko wrote: 2012/3/30 Osipov, Michael michael.osi...@siemens.com: Filip Hanik (mailing lists) wrote: http://svn.apache.org/viewvc?view=revisionrevision=1306946 Thanks for the patch, I am having trouble to build from source. I do have some test failures, should I ignore them and go on? Please be more specific. In what tests? Have a look at this: http://pastebin.com/kiHLF6D9 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [JDBC Pool] PoolCleaner creates some sort of memory
Filip Hanik (mailing lists) wrote: PoolCleaner is a static singleton. The pool cleaner thread will not be removed until all JDBC pools have been stopped. So, yes, one application can be the one that starts the thread, but not necessarily the one that stops it Filip, I have already noticed that but the point is that the log message is misleading as same as the name of the thread. Something like 'Tomcat JBDC Pool Cleaner Task would be much clearer. Mike
RE: [JDBC Pool] PoolCleaner creates some sort of memory
http://svn.apache.org/viewvc?view=revisionrevision=1306946 -Original Message- From: Osipov, Michael [mailto:michael.osi...@siemens.com] Sent: Thursday, March 29, 2012 1:36 AM To: Tomcat Users List Subject: RE: [JDBC Pool] PoolCleaner creates some sort of memory - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[JDBC Pool] PoolCleaner creates some sort of memory
Hi folks, Recently this started to pop up in my logs: 23.03.2012 14:12:28 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SCHWERWIEGEND: The web application [/ket] appears to have started a thread named [PoolCleaner[18291494:1332172047553]] but has failed to stop it. This is very likely to create a memory leak. There is some similar thread [1] which had no real result. I am on Tomcat 6.0.35, all DataSources are created in the context.xml file. All DataSources are cleaned up (closed) with a context.xml Listener. The JDBC Pool is version 7.0.26. As far as my debug sessions have revealed (with attached VisualVM), it does not matter how many apps you deploy the PoolCleanTimer thread is created only once and retained until all apps have been stopped or removed. This makes Tomcat think that this is a memory leak. Is there a way to associate this thread with another class loader in order to avoid this problem or create multiple threads or simple ignore this warning which is not a solution for those who face that issue too? Besides that, the numbers in the thread name are not very informative, the classloader hashcode and timestamp did not really help to to identify anything. Can this be improved? [1] http://www.mail-archive.com/users@tomcat.apache.org/msg87350.html With best regards, Michael Osipov - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [JDBC Pool] PoolCleaner creates some sort of memory
2012/3/28 Osipov, Michael michael.osi...@siemens.com: Hi folks, Recently this started to pop up in my logs: 23.03.2012 14:12:28 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SCHWERWIEGEND: The web application [/ket] appears to have started a thread named [PoolCleaner[18291494:1332172047553]] but has failed to stop it. This is very likely to create a memory leak. There is some similar thread [1] which had no real result. I am on Tomcat 6.0.35, all DataSources are created in the context.xml file. All DataSources are cleaned up (closed) with a context.xml Listener. The JDBC Pool is version 7.0.26. As far as my debug sessions have revealed (with attached VisualVM), it does not matter how many apps you deploy the PoolCleanTimer thread is created only once and retained until all apps have been stopped or removed. This makes Tomcat think that this is a memory leak. Is there a way to associate this thread with another class loader in order to avoid this problem or create multiple threads or simple ignore this warning which is not a solution for those who face that issue too? Is there a way to start it before webapps are started? Something similar exists in the following listener: Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / At Tomcat startup it calls different API methods that are known to create such classloader-bound objects. Is there a way to associate this thread with another class loader Thread.setContextClassLoader() ? But IIRC this method is not thread-safe. Besides that, the numbers in the thread name are not very informative, the classloader hashcode and timestamp did not really help to to identify anything. Can this be improved? What would you like to see there? Thread names are not under our control. Anything else that can be obtained through API calls can be added. Suggestions are welcome. See the code -- search for webappClassLoader.warnThread in org/apache/catalina/loader/WebappClassLoader.java [1] http://www.mail-archive.com/users@tomcat.apache.org/msg87350.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [JDBC Pool] PoolCleaner creates some sort of memory
Konstantin Kolinko wrote: 2012/3/28 Osipov, Michael michael.osi...@siemens.com: Hi folks, Recently this started to pop up in my logs: 23.03.2012 14:12:28 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SCHWERWIEGEND: The web application [/ket] appears to have started a thread named [PoolCleaner[18291494:1332172047553]] but has failed to stop it. This is very likely to create a memory leak. There is some similar thread [1] which had no real result. I am on Tomcat 6.0.35, all DataSources are created in the context.xml file. All DataSources are cleaned up (closed) with a context.xml Listener. The JDBC Pool is version 7.0.26. As far as my debug sessions have revealed (with attached VisualVM), it does not matter how many apps you deploy the PoolCleanTimer thread is created only once and retained until all apps have been stopped or removed. This makes Tomcat think that this is a memory leak. Is there a way to associate this thread with another class loader in order to avoid this problem or create multiple threads or simple ignore this warning which is not a solution for those who face that issue too? Is there a way to start it before webapps are started? Something similar exists in the following listener: Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / At Tomcat startup it calls different API methods that are known to create such classloader-bound objects. Is there a way to associate this thread with another class loader Thread.setContextClassLoader() ? But IIRC this method is not thread-safe. I am aware of that method but that was not my point. I guess that could best answered by Mark or Filip. If this TimerTask could be associated with the Bootstrap CL, there would be no warning. Besides that, the numbers in the thread name are not very informative, the classloader hashcode and timestamp did not really help to to identify anything. Can this be improved? What would you like to see there? Thread names are not under our control. Anything else that can be obtained through API calls can be added. Suggestions are welcome. See the code -- search for webappClassLoader.warnThread in org/apache/catalina/loader/WebappClassLoader.java The warning itself is ok but not the thread name. The thread name here is under implementor's control. See here [1]. The name can easily be confused with Oracle's LDAP Connection PoolCleaner. Something Tomcat JDBC Pool Cleaner[hexid] would have helped me to find that one way faster. [1] http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java?view=markup#l1216 With best regards, Michael Osipov Siemens AG Industry Sector Drive Technologies Division I DT IT LD BLN Nonnendammallee 72 13629 Berlin, Germany mailto:michael.osi...@siemens.com Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [JDBC Pool] PoolCleaner creates some sort of memory
PoolCleaner is a static singleton. The pool cleaner thread will not be removed until all JDBC pools have been stopped. So, yes, one application can be the one that starts the thread, but not necessarily the one that stops it Filip -Original Message- From: Osipov, Michael [mailto:michael.osi...@siemens.com] Sent: Wednesday, March 28, 2012 8:29 AM To: users@tomcat.apache.org Subject: [JDBC Pool] PoolCleaner creates some sort of memory Hi folks, Recently this started to pop up in my logs: 23.03.2012 14:12:28 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SCHWERWIEGEND: The web application [/ket] appears to have started a thread named [PoolCleaner[18291494:1332172047553]] but has failed to stop it. This is very likely to create a memory leak. There is some similar thread [1] which had no real result. I am on Tomcat 6.0.35, all DataSources are created in the context.xml file. All DataSources are cleaned up (closed) with a context.xml Listener. The JDBC Pool is version 7.0.26. As far as my debug sessions have revealed (with attached VisualVM), it does not matter how many apps you deploy the PoolCleanTimer thread is created only once and retained until all apps have been stopped or removed. This makes Tomcat think that this is a memory leak. Is there a way to associate this thread with another class loader in order to avoid this problem or create multiple threads or simple ignore this warning which is not a solution for those who face that issue too? Besides that, the numbers in the thread name are not very informative, the classloader hashcode and timestamp did not really help to to identify anything. Can this be improved? [1] http://www.mail-archive.com/users@tomcat.apache.org/msg87350.html With best regards, Michael Osipov - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [JDBC Pool] PoolCleaner creates some sort of memory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip, On 3/28/12 12:00 PM, Filip Hanik (mailing lists) wrote: PoolCleaner is a static singleton. The pool cleaner thread will not be removed until all JDBC pools have been stopped. So, yes, one application can be the one that starts the thread, but not necessarily the one that stops it Is there any reason not to associate the thread with the WebappClassLoader's parent? Otherwise, this will pin the first webapp to use tomcat-pool in memory until all webapps have been undeployed, right? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9zPQkACgkQ9CaO5/Lv0PD7wwCeOR3bVeJOk6fyWsTtzE3Fpbzm Bk8AnjrsNqyp3zsHexJhIuLumEgZ1fsj =pI1I -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [JDBC Pool] PoolCleaner creates some sort of memory
: SHA1 Filip, On 3/28/12 12:00 PM, Filip Hanik (mailing lists) wrote: PoolCleaner is a static singleton. The pool cleaner thread will not be removed until all JDBC pools have been stopped. So, yes, one application can be the one that starts the thread, but not necessarily the one that stops it Is there any reason not to associate the thread with the WebappClassLoader's parent? Otherwise, this will pin the first webapp to use tomcat-pool in memory until all webapps have been undeployed, right? [Filip Hanik] Correct, I can add in a fix for this to force the context classloader to be the same as the pool while it is starting the thread - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9zPQkACgkQ9CaO5/Lv0PD7wwCeOR3bVeJOk6fyWsTtzE3Fp bzm Bk8AnjrsNqyp3zsHexJhIuLumEgZ1fsj =pI1I -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
