If I understand it correctly, the InheritedThreadLocal (ITL) wil hold the Application reference only if its corresponding thread stays alive. If the thread dies, the ITL value is eligible for gc, right?
Well, if your application creates a new thread, that is kept alive even after the webapp is undeployed, the leak is the living thread, not the ITL. This thread will probably also make some reference to application classes (if not, why was it created in the first place?), which will cause the same memory leak. And, if the thread is taken from a pool managed by some lightweight container, e.g. Spring, the ITL will not inherit the Application value, since the 'working' thread is not a child of the request thread. Well, maybe there is some corner case, for example, if the thread pool implementation creates new threads on demand, and make them children of the requesting threads and thus, inheriting the Application instance (this should probably be considered a bug of the pool implementation). Even then, it will only be a problem if the pool is managed by something outside the application, because its threads must survive the web app undeployment to cause a leak. Well, I tried to think of some problematic case (since I was worried about this, too), but couldn't. Do you have any case with potential to trigger the leak? Tetsuo On Wed, May 19, 2010 at 1:15 PM, Adriano dos Santos Fernandes < [email protected]> wrote: > On 19/05/2010 13:06, Alex Objelean wrote: > >> Please, correct me if I'm wrong, but the Application won't become the root >> of >> child threads. Using InheritableThreadLocal will only make Application >> available from the threads created during a request cycle. There is >> absolutely no memory related problem with it. >> >> > As I said, some operations may spawn threads, like manipulation images, for > example. > > If your application call it (during a request cycle), the application > object will be stored in a system thread. > > Take a look at this: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489540 > > This currently make web-classloader leaks. If you start using > InheritableThreadLocal's with arbitrary objects, you're going to make even > more leaks. > > Also note, there is something not good here. AFAIK, Wicket sets the thread > locals only during the request. But if child threads are spawned, they can't > be cleaned automatically. IMO, it should be done something that the user > needs to call to set/clear this, like a specialized WicketThread class. > > > Adriano > >
