On 29/04/2010 21:50, Sylvain Laurent wrote: > 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.
Are you saying that you want to stop processing requests each time a webapp gets restarted, or that the thread pool is refreshed by sequentially killing each thread and recreating it? p > 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 >
signature.asc
Description: OpenPGP digital signature
