Summary: | WebAppClassLoader.clearThreadLocalMap() concurrency issues | ||
---|---|---|---|
Product: | Tomcat 6 | Reporter: | Sylvain Laurent <slaurent> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 6.0.24 | ||
Target Milestone: | default | ||
Hardware: | All | ||
OS: | All |
Description
Sylvain Laurent
2010-03-11 22:20:01 UTC
This has been fixed in trunk and proposed for 6.0.x Thanks for the change. So, I guess now we can safely clean thread locals only in threads controlled by tomcat (i.e. worker threads) and by one of these 2 methods : - either renew threads in the pool - cleanup all threadlocals after each request when the thread is returned to the pool (during the call to ThreadPoolExecutor.afterExecute() ) This has been made optional in 6.0.x and will be included in 6.0.27 onwards. I'll create a new BZ enhancement for Tomcat 7 to track the better ways of doing this. If the only threads accessing the instances of a context are the connector's threads, and if you kill those threads when you remove a context, then you cannot have a leak. Sadly, tomcat is ass backwards and has a pool of thread per connectors owned by the service instead of owned by the context. Thus you cannot destroy threads without destroying all context under all hosts under all engines under the service. Solution: destroying a context must mark a thread that visited it for termination, asap. That means the thread would not return in the pool, and the pool would create a replacement thread. That is subpar for other ctx/host/engine that would loose the threadlocal-cached values, but it is not a requirement for j2ee to be efficient under such operation, and the app is still supposed to work as it should expect a threadlocal to be null at any time. |