-----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
