Re: using clearReferencesStopTimerThreads value for context
On 27/06/2012 03:04, Supun Malinga wrote: Hi all, Say I have a webapp that don't stop all the timer threads it started upon the webapp undeploy/stop. So tomcat prints an error, The web application [/NewStratosDBAccessServlet] appears to have started a thread named [MySQL Statement Cancellation Timer] but has failed to stop it. This is very likely to create a memory leak. The error says severe and we need to take some action against it. Therefore I set clearReferencesStopTimerThreads property to webapp context. Now tomcat prints, *SEVERE*: The web application [/NewStratosDBAccessServlet] appears to have started a TimerThread named [Timer-8] via the java.util.Timer API but has failed to stop it. To prevent a memory leak, the timer (and hence the associated thread) has been *forcibly canceled*. Thought it indicates the timer threads are cleared the log is still SEVERE. May I know the intention of keeping it as SEVERE ? Because the web application still has a bug. Whether or not Tomcat is working around it is irrelevant to the severity of the bug in the web application. All memory leaks of this nature are reported as errors. Wouldn't it be of WARN or perhaps INFO ? Nope. Any help is highly appreciated.. Getting rid of that message is simple. Fix the bug in the web application. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: using clearReferencesStopTimerThreads value for context
Hi, On Wed, Jun 27, 2012 at 1:42 PM, Mark Thomas ma...@apache.org wrote: On 27/06/2012 03:04, Supun Malinga wrote: Hi all, Say I have a webapp that don't stop all the timer threads it started upon the webapp undeploy/stop. So tomcat prints an error, The web application [/NewStratosDBAccessServlet] appears to have started a thread named [MySQL Statement Cancellation Timer] but has failed to stop it. This is very likely to create a memory leak. The error says severe and we need to take some action against it. Therefore I set clearReferencesStopTimerThreads property to webapp context. Now tomcat prints, *SEVERE*: The web application [/NewStratosDBAccessServlet] appears to have started a TimerThread named [Timer-8] via the java.util.Timer API but has failed to stop it. To prevent a memory leak, the timer (and hence the associated thread) has been *forcibly canceled*. Thought it indicates the timer threads are cleared the log is still SEVERE. May I know the intention of keeping it as SEVERE ? Because the web application still has a bug. Whether or not Tomcat is working around it is irrelevant to the severity of the bug in the web application. All memory leaks of this nature are reported as errors. I see.. thanks for the clarification! Wouldn't it be of WARN or perhaps INFO ? Nope. Any help is highly appreciated.. Getting rid of that message is simple. Fix the bug in the web application. thanks, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Supun Malinga
Re: using clearReferencesStopTimerThreads value for context
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark,
On 6/27/12 4:12 AM, Mark Thomas wrote:
Getting rid of that message is simple. Fix the bug in the web
application.
+1
FWIW, Oracle/MySQL says that this bug has been fixed in Connector/J
5.1.11 (http://bugs.mysql.com/bug.php?id=36565). If you can't upgrade,
you might have some success with a ServletContextListener with the
following contextDestroyed method:
public void contextDestroyed(ServletContextEvent e)
{
try
{
ClassLoader myClassLoader = this.getClass().getClassLoader();
Class clazz = Class.forName(com.mysql.jdbc.ConnectionImpl,
false,
myClassLoader);
if(!(clazz.getClassLoader() == myClassLoader))
{
log.info(MySQL ConnectionImpl was loaded with another
ClassLoader: ( + clazz.getClassLoader() + ): cancelling anyway);
}
else
{
log.info(MySQL ConnectionImpl was loaded with the
WebappClassLoader: cancelling the Timer);
}
Field f = clazz.getDeclaredField(cancelTimer);
f.setAccessible(true);
Timer timer = (Timer) f.get(null);
timer.cancel();
log.info(completed timer cancellation);
}
catch (ClassNotFoundException cnfe)
{
// Ignore
log.error(Cannot cancel, cnfe);
}
catch (NoSuchFieldException nsfe)
{
// Ignore
log.error(Cannot cancel, nsfe);
}
catch (SecurityException se)
{
log.info(Failed to shut-down MySQL Statement Cancellation
Timer due to a SecurityException, se);
}
catch (IllegalAccessException iae)
{
log.info(Failed to shut-down MySQL Statement Cancellation
Timer due to an IllegalAccessException, iae);
}
}
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/rI+4ACgkQ9CaO5/Lv0PBu5gCgw6GPz8gGEgS+yjeJDK20krPA
ugMAnRtm4r3ehNIG/cZhGeU/yS1pIhBY
=eHCR
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
using clearReferencesStopTimerThreads value for context
Hi all, Say I have a webapp that don't stop all the timer threads it started upon the webapp undeploy/stop. So tomcat prints an error, The web application [/NewStratosDBAccessServlet] appears to have started a thread named [MySQL Statement Cancellation Timer] but has failed to stop it. This is very likely to create a memory leak. The error says severe and we need to take some action against it. Therefore I set clearReferencesStopTimerThreads property to webapp context. Now tomcat prints, *SEVERE*: The web application [/NewStratosDBAccessServlet] appears to have started a TimerThread named [Timer-8] via the java.util.Timer API but has failed to stop it. To prevent a memory leak, the timer (and hence the associated thread) has been *forcibly canceled*. Thought it indicates the timer threads are cleared the log is still SEVERE. May I know the intention of keeping it as SEVERE ? Wouldn't it be of WARN or perhaps INFO ? Any help is highly appreciated.. thanks, -- Supun Malinga,
