You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2016/12/22 14:31:25 UTC

Tomcat can report that a request-processing thread was started by an application?

All,

I was browsing the Tomcat-related questions on SO and I noticed this one:

http://stackoverflow.com/questions/41223141/threads-in-tomcat-memory-leaks

The poster shows a snip of his error log which says this:

дек 19, 2016 12:25:10 AM
org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads
SEVERE: The web application [/someContext] appears to have started a
thread named [http-apr-8081-exec-10] but has failed to stop it. This is
very likely to create a memory leak.

That seems like an incorrect -- and very confusing -- error message.

The use-case was undeploying an application while a request was being
handled (your basic Thread.sleep() to hold a request in-flight in order
to undeploy during that time). This was with Tomcat 7 (no specific
version number).

It also seems like in that case, Tomcat may forcibly-change the TCCL of
the in-flight request-processing thread, bus it's not quite clear to me
precisely what's going on.

-chris


Re: Tomcat can report that a request-processing thread was started by an application?

Posted by Rémy Maucherat <re...@apache.org>.
2016-12-22 15:31 GMT+01:00 Christopher Schultz <chris@christopherschultz.net
>:

> All,
>
> I was browsing the Tomcat-related questions on SO and I noticed this one:
>
> http://stackoverflow.com/questions/41223141/threads-in-tomcat-memory-leaks
>
> The poster shows a snip of his error log which says this:
>
> дек 19, 2016 12:25:10 AM
> org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads
> SEVERE: The web application [/someContext] appears to have started a
> thread named [http-apr-8081-exec-10] but has failed to stop it. This is
> very likely to create a memory leak.
>
> That seems like an incorrect -- and very confusing -- error message.
>
> The use-case was undeploying an application while a request was being
> handled (your basic Thread.sleep() to hold a request in-flight in order
> to undeploy during that time). This was with Tomcat 7 (no specific
> version number).
>
> It also seems like in that case, Tomcat may forcibly-change the TCCL of
> the in-flight request-processing thread, bus it's not quite clear to me
> precisely what's going on.
>
> It's mostly as expected. The servlet unloading waits for an unload delay
(2s) then moves on. The thread is then flagged as a possible leak, which is
true. The odd thing is that there's code to identify a request thread, and
it's not reported as one (the code looks like it will work, so I don't
understand). Maybe this check was not present in the version that is being
used.

Rémy