You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Supun Malinga <su...@wso2.com> on 2012/06/27 04:04:48 UTC
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,
Re: using clearReferencesStopTimerThreads value for context
Posted by Supun Malinga <su...@wso2.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Supun Malinga
Re: using clearReferencesStopTimerThreads value for context
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: using clearReferencesStopTimerThreads value for context
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org