Thanks for the quick reply, Mark. Much appreciated. I was afraid that was the case.
What I was trying to accomplish was...data that's not request/response specific in any way, that survives requests. I was using ThreadLocal so as to make it non-blocking, i.e. I didn't want to centralize management of this stuff and have to synchronize access to it across my hundreds of executor threads. Sounds like I'll need to bite the bullet on that. Oh well... :-) On Tue, Sep 20, 2011 at 2:55 PM, Mark Thomas <ma...@apache.org> wrote: > On 20/09/2011 19:29, Dan Checkoway wrote: > > I'm curious how long Executor threads live prior to being > > recycled/replaced/what have you. Is there a way to control this > lifecycle? > > No. > > > I'm using ThreadLocal to allocate some resources per thread... > > That is asking for a memory leak. There is a simple rule for correctly > using a ThreadLocal in a web application. > > The ThreadLocal must be removed from the thread before the > request/response in which it was created completes processing. > > > and the > > behavior I'm seeing is that after some period of time, my > ThreadLocal<Thing> > > goes away and needs to be reinitialized. It's implying to me that the > > thread itself has been recycled. > > More recent versions of Tomcat will re-cycle threads and/or remove > ThreadLocals detected when an application is reloaded as part of the > memory leak prevention code. > > > What's making this more confusing is that the thread IDs appear to be > > getting reused, so logging the thread ID isn't helping (it's probably > > confusing me more than anything). > > > > Anyway, can somebody confirm if Tomcat has explicit deliberate control > over > > the Executor thread lifecycle, and if so, how I might be able to control > > it? And if not, is there a way to control it? > > ThreadLocals are likely to be the wrong solution to the problem. If you > need a resource across multiple, unrelated requests, the ServletContext > is probably the way to go. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
