Re: Memory Leakage Problem in Tomcat 7.0.94
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ankit, On 10/11/19 00:52, ankitr.de...@spec-india.com wrote: >> 1. Allow Tomcat to clear these references, and otherwise ignore >> the error messages> > Can you please let us know how to Allow Tomcat to clear these> > references? Have another look at the log message: >> SEVERE: The web application [/TLSAdmin] created a ThreadLocal >> with key of type [java.lang.ThreadLocal] (value >> [java.lang.ThreadLocal@794fa987]) and a value of type >> [flex.messaging.config.SystemSettings] (value >> [flex.messaging.config.SystemSettings@7dca495e]) but failed to >> remove it when the web application was stopped. Threads are going >> to be renewed over time to try and avoid a probable memory leak. Tomcat is already protecting the heap by clearing these ThreadLocal references for you. It may take some time, and your application won't cleanly undeploy until all the threads have been "renewed". - -chris > -Original Message- From: Christopher Schultz > Sent: 10 October 2019 11:08 PM To: > users@tomcat.apache.org Subject: Re: Memory Leakage Problem in > Tomcat 7.0.94 > > Ankit, > > On 10/10/19 10:17, ankitr.de...@spec-india.com wrote: >> We are using Tomcat 7.0.94 version and we have facing memory >> leakage issue when tomcat server is going to shutdown. > >> Please help in this case, how to solve these kind of logs? > >> Please find below sample logs from catalina.log file and code. > > > >> Oct 10, 2019 6:35:36 PM >> org.apache.catalina.loader.WebappClassLoaderBase >> clearReferencesThreads > >> SEVERE: The web application [/TLSAdmin] appears to have started a >> thread named [Timer-0] but has failed to stop it. This is very >> likely to create a memory leak. > > Your application started this thread and hasn't stopped it. (See > below) > >> Oct 10, 2019 6:35:36 PM >> org.apache.catalina.loader.WebappClassLoaderBase >> clearReferencesThreads > >> SEVERE: The web application [/TLSAdmin] appears to have started a >> thread named [schedulerFactory_Worker-1] but has failed to stop >> it. This is very likely to create a memory leak. > > Same here, except it's likely to be a thread pool with a number of > threads with similar names. > > To fix the thread issues, you need to find the place in your code > where the threads are started (or the threadpool is created) and > make sure that you have access to that thread (or pool) during > application shutdown. Storing stuff like this in the application > (context) scope is one way to do it. > > I would recommend another ServletContextListener that locates those > threads (pools) and stops them. Remember that Thread.stop() doesn't > really work. Instead, you have to let the thread know that it's > time to stop itself. > > Threads called "Timer-X" are usually simple threads created by > java.util.TimerTask and friends, and you should be able to store a > reference to the task and stop it on app shutdown. > >> [snip] > >> Oct 10, 2019 6:35:36 PM >> org.apache.catalina.loader.WebappClassLoaderBase >> checkThreadLocalMapForLeaks > >> SEVERE: The web application [/TLSAdmin] created a ThreadLocal >> with key of type [java.lang.ThreadLocal] (value >> [java.lang.ThreadLocal@794fa987]) and a value of type >> [flex.messaging.config.SystemSettings] (value >> [flex.messaging.config.SystemSettings@7dca495e]) but failed to >> remove it when the web application was stopped. Threads are going >> to be renewed over time to try and avoid a probable memory leak. > > Something in "flex" has put an object in ThreadLocal storage and > never removed it. This is harder to fix than the threading stuff > because you each thread needs to purge the ThreadLocal objects in > order to "clean" the system. > > You have two options, really: > > 1. Allow Tomcat to clear these references, and otherwise ignore the > error messages. > > 2. Change your application so that at the end of each request you > remove these ThreadLocal values from the request-processing > thread. > > Hope that helps, -chris > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2gj7EACgkQHPApP6U8 pFhDmQ/9GAOJC1DyXiJQ8vMYi6l9s+DfuMFyCDJniuF+AqcHJ9e0k+2aDtETqR/z xGyAoia3nFrLwRXdQAPRqfZDyLAJijW
RE: Memory Leakage Problem in Tomcat 7.0.94
HI Christopher, Thanks for you valuable reply, >>>1. Allow Tomcat to clear these references, and otherwise ignore the error messages. Can you please let us know how to Allow Tomcat to clear these references? --Ankit -Original Message- From: Christopher Schultz Sent: 10 October 2019 11:08 PM To: users@tomcat.apache.org Subject: Re: Memory Leakage Problem in Tomcat 7.0.94 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ankit, On 10/10/19 10:17, ankitr.de...@spec-india.com wrote: > We are using Tomcat 7.0.94 version and we have facing memory leakage > issue when tomcat server is going to shutdown. > > Please help in this case, how to solve these kind of logs? > > Please find below sample logs from catalina.log file and code. > > > > Oct 10, 2019 6:35:36 PM > org.apache.catalina.loader.WebappClassLoaderBase > clearReferencesThreads > > SEVERE: The web application [/TLSAdmin] appears to have started a > thread named [Timer-0] but has failed to stop it. This is very likely > to create a memory leak. Your application started this thread and hasn't stopped it. (See below) > Oct 10, 2019 6:35:36 PM > org.apache.catalina.loader.WebappClassLoaderBase > clearReferencesThreads > > SEVERE: The web application [/TLSAdmin] appears to have started a > thread named [schedulerFactory_Worker-1] but has failed to stop it. > This is very likely to create a memory leak. Same here, except it's likely to be a thread pool with a number of threads with similar names. To fix the thread issues, you need to find the place in your code where the threads are started (or the threadpool is created) and make sure that you have access to that thread (or pool) during application shutdown. Storing stuff like this in the application (context) scope is one way to do it. I would recommend another ServletContextListener that locates those threads (pools) and stops them. Remember that Thread.stop() doesn't really work. Instead, you have to let the thread know that it's time to stop itself. Threads called "Timer-X" are usually simple threads created by java.util.TimerTask and friends, and you should be able to store a reference to the task and stop it on app shutdown. > [snip] > Oct 10, 2019 6:35:36 PM > org.apache.catalina.loader.WebappClassLoaderBase > checkThreadLocalMapForLeaks > > SEVERE: The web application [/TLSAdmin] created a ThreadLocal with key > of type [java.lang.ThreadLocal] (value > [java.lang.ThreadLocal@794fa987]) and a value of type > [flex.messaging.config.SystemSettings] (value > [flex.messaging.config.SystemSettings@7dca495e]) but failed to remove > it when the web application was stopped. Threads are going to be > renewed over time to try and avoid a probable memory leak. Something in "flex" has put an object in ThreadLocal storage and never removed it. This is harder to fix than the threading stuff because you each thread needs to purge the ThreadLocal objects in order to "clean" the system. You have two options, really: 1. Allow Tomcat to clear these references, and otherwise ignore the error messages. 2. Change your application so that at the end of each request you remove these ThreadLocal values from the request-processing thread. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2fbHsACgkQHPApP6U8 pFhmTg/7BPeaBmZ073LRDTc6Am3HkEtpL8ZKzuN1utqc0EsYlzJAUc1G4nBHenuE HM6FDDKOXcKa7nQnN+A63S9zMu0b/K9HZT+bA6TFpIeypx//c8lcxAxqwFJLXaQS IE5YU0cmBc3njMpHSUqE16/dRl1KoyJWWwqUSXDVsJLA/RTaheOq14T0BjaTDSaN dgX+80mbovwkwKzhbZETGP2OY+wJ0GGje3FtXqdFqPp6evlaekHRNXC0N+4VHSNe XNkfjkfdJldAulpbxPj5eulg5ONyQVRHG3nRSUHeH7Q0v4uhjy7tYcd7PwVLr3s1 RzFeK35gqRYmVXGqf+kEMLkBQbW04LEAukzG5SZPpGHLkyL10dBv3Z7eulILiwP0 +pm79SluHi1nHGd6CSzrMc+Sv9FF8hxwxkph2i/Ec3w/j6/hNvD+whJgEQh44mbF MiGTs58OJEyICjUfFhcAVEvrkcDSzq/kmgL57dCm2P/LGzieH611fB0ipSMzcmpD Pt21ATqWEKWJrecMc2qAo44jPxbW0FEcbmFNSKfMUOYWg3KDiOrH32Byb9OPFrgq RxKmNRx0KBWZUnj+yZKp71l3OOmrFswfDnGIigm2k9aVuY0s3FcJfAUM20/wAG+W rDropeU+g+2wmo7Ak0ZoZR8zcoh1j7PrWFld36XNVMxoT38aFjY= =ZMog -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
Re: Memory Leakage Problem in Tomcat 7.0.94
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ankit, On 10/10/19 10:17, ankitr.de...@spec-india.com wrote: > We are using Tomcat 7.0.94 version and we have facing memory > leakage issue when tomcat server is going to shutdown. > > Please help in this case, how to solve these kind of logs? > > Please find below sample logs from catalina.log file and code. > > > > Oct 10, 2019 6:35:36 PM > org.apache.catalina.loader.WebappClassLoaderBase > clearReferencesThreads > > SEVERE: The web application [/TLSAdmin] appears to have started a > thread named [Timer-0] but has failed to stop it. This is very > likely to create a memory leak. Your application started this thread and hasn't stopped it. (See below) > Oct 10, 2019 6:35:36 PM > org.apache.catalina.loader.WebappClassLoaderBase > clearReferencesThreads > > SEVERE: The web application [/TLSAdmin] appears to have started a > thread named [schedulerFactory_Worker-1] but has failed to stop it. > This is very likely to create a memory leak. Same here, except it's likely to be a thread pool with a number of threads with similar names. To fix the thread issues, you need to find the place in your code where the threads are started (or the threadpool is created) and make sure that you have access to that thread (or pool) during application shutdown. Storing stuff like this in the application (context) scope is one way to do it. I would recommend another ServletContextListener that locates those threads (pools) and stops them. Remember that Thread.stop() doesn't really work. Instead, you have to let the thread know that it's time to stop itself. Threads called "Timer-X" are usually simple threads created by java.util.TimerTask and friends, and you should be able to store a reference to the task and stop it on app shutdown. > [snip] > Oct 10, 2019 6:35:36 PM > org.apache.catalina.loader.WebappClassLoaderBase > checkThreadLocalMapForLeaks > > SEVERE: The web application [/TLSAdmin] created a ThreadLocal with > key of type [java.lang.ThreadLocal] (value > [java.lang.ThreadLocal@794fa987]) and a value of type > [flex.messaging.config.SystemSettings] (value > [flex.messaging.config.SystemSettings@7dca495e]) but failed to > remove it when the web application was stopped. Threads are going > to be renewed over time to try and avoid a probable memory leak. Something in "flex" has put an object in ThreadLocal storage and never removed it. This is harder to fix than the threading stuff because you each thread needs to purge the ThreadLocal objects in order to "clean" the system. You have two options, really: 1. Allow Tomcat to clear these references, and otherwise ignore the error messages. 2. Change your application so that at the end of each request you remove these ThreadLocal values from the request-processing thread. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2fbHsACgkQHPApP6U8 pFhmTg/7BPeaBmZ073LRDTc6Am3HkEtpL8ZKzuN1utqc0EsYlzJAUc1G4nBHenuE HM6FDDKOXcKa7nQnN+A63S9zMu0b/K9HZT+bA6TFpIeypx//c8lcxAxqwFJLXaQS IE5YU0cmBc3njMpHSUqE16/dRl1KoyJWWwqUSXDVsJLA/RTaheOq14T0BjaTDSaN dgX+80mbovwkwKzhbZETGP2OY+wJ0GGje3FtXqdFqPp6evlaekHRNXC0N+4VHSNe XNkfjkfdJldAulpbxPj5eulg5ONyQVRHG3nRSUHeH7Q0v4uhjy7tYcd7PwVLr3s1 RzFeK35gqRYmVXGqf+kEMLkBQbW04LEAukzG5SZPpGHLkyL10dBv3Z7eulILiwP0 +pm79SluHi1nHGd6CSzrMc+Sv9FF8hxwxkph2i/Ec3w/j6/hNvD+whJgEQh44mbF MiGTs58OJEyICjUfFhcAVEvrkcDSzq/kmgL57dCm2P/LGzieH611fB0ipSMzcmpD Pt21ATqWEKWJrecMc2qAo44jPxbW0FEcbmFNSKfMUOYWg3KDiOrH32Byb9OPFrgq RxKmNRx0KBWZUnj+yZKp71l3OOmrFswfDnGIigm2k9aVuY0s3FcJfAUM20/wAG+W rDropeU+g+2wmo7Ak0ZoZR8zcoh1j7PrWFld36XNVMxoT38aFjY= =ZMog -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
