If I understand you and your comment here https://issues.apache.org/bugzilla/show_bug.cgi?id=49159#c2 you propose to clean only thread locals loaded by a web app. But how do you recognize them ? If the value bound to a threadlocal is an ArrayList, you won't be able to tell that it was loaded by a webapp. Furthermore, there is probably some frameworks out there that do save things in ThreadLocals in a manner that does not cause classloader leaks but improve their performance. Cleaning their threadlocals after each request would decrease their performance.
I'm rather in favor of renewing the threads of the pool when a webapp is being stopped. I have a prototype (very early stage) with a new method in StandardThreaExecutor that recreates a ThreadPoolExecutor instance when invoked. With a specific LifecycleListener declared in server.xml which registers itself as a LifecycleListener on every Context, it calls this new renewThreads method when the after_stop event of a Context is fired. The renewThreads method is called on each Executor of each EndPoint of each Connector, provided it is a StandardThreadExecutor. It works well to avoid threadLocal-related leaks, and it has no impact for request processing. There's only an impact when an application is stopped : all threads in the pool(s) are shutdown (once they have no more work to do in the TaskQueue) and new threads are recreated. Thus for heavily loaded servers there is probably a decrease in throughput while new threads are being created, but in my opinion this is an acceptable price to pay for a welcome memory leak protection. Anyways, the feature can be disabled by simply commenting the listener in server.xml. I still have to polish the thing before proposing a patch : - make sure the lifecycleListener is registered for new Context/Host/Service added dynamically - check what happens when a Context fails to start - exception handling - various cleanups... Regarding tomcat 6 compatibility, I did not check yet. But having this feature for TC7 might be an incentive to upgrade ;-) Sylvain On 29 avr. 2010, at 01:36, Mark Thomas wrote: > On 27/04/2010 15:57, Sylvain Laurent wrote: >> Do you mean one declared in server.xml ? or have the StandardThreadExecutor >> register itself as a LifeCycleListener ? In the latter case, my problem is >> how do I get a reference to StandardContext instances from the >> StandardThreadExecutor ? > > I'm not sure this is the way to go. It isn't going to work for Tomcat 6. I > think cleaning the threads when they return to the pool may be the more > viable option. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
