Nice and all that you can tie resources and stuff to a Thread and than deeper down in your call stack retrieve them again, but obviously, people are using them for the wrong purposes without thinking about potential problems that might cause! One of the consequences of incorrectly using ThreadLocals is that it prevents webapplications from being redeployable. Okay, in a production environment, you probably don’t do hot-deployments, but still.
Today I chased down a memory/redeployment issue in Tomcat for a client of mine. The usual stuff: after a bit of profiling it showed that the classloader of an undeployed application couldn’t be cleaned up, due to the use of ThreadLocals. In org.apache.axis.Service a Call object is created and kept around for whatever reasons in a ThreadLocal. The createCall() method returns the call immediately and doesn’t bother about the ThreadLocal anymore. Without inspecting the code and thorougly profiling the application you don’t have a clue of what’s going on. We’ll probably create a patch ourselves to solve this specific problem.
This is about the twentieth time I’ve seen clients with problems that had to deal with the use of ThreadLocals. This clearly indicates that somewhere there should be warnings that the evil ThreadLocal should be used with caution, or at least only when you know you have to unset it again in a multi-threaded server environment.
By the way, it’s not like I think ThreadLocals should be removed from Java. They’re an excellent way to implement the passing of context information (as Ted Neward dubbed it the context pattern once I think) and it’s heavily used (in a proper way!) in the Spring Framework. You should 1) know what you’re doing and 2) clean your own mess up and not leave it for somebody else to call ThreadLocal.set(null);!
Can you please elaborate a bit more on the bug you hit.
Why shouldn’t the classloader be elibigle for GC? Kindly post a link where I can find more on this.
Thanks,
Binil
I agree. It’s probably best to set and clear them only within a single try-finally block.
While
ThreadLocals might be useful, I still think of them of a hack. A useful hack, but a hack none the less. To me, they smell too much like C-like global variables, which I learned were evil.I assume Axis is within tomcat’s lib directory (tomcate/lib), rather than that of the web app (tomcate/webapps/myapp/WEB-INF/lib). So a ThreadLocal within Axis with a direct or indirect reference to an item loaded through the web app ClassLoader could act as a live reference to the old classes.
Should, perhaps, threads be limited to a single web app? That is, each web app have a private thread pool, which is discarded on reload.
Anyway: thread locals may seem like a good idea, but never really do what you want.
Tom, Axis is placed in WEB-INF/lib, just like any other dependency (except for the drivers and Tomcat security related stuff) to keep things clean and to be able to deploy different versions of dependency in the same Tomcat. I’ll work out a simple sample to show the behavior soon.
Threadlocals are excellent – if people misuse them and create bugs, then that’s bad, but don’t blame a very useful part of the API. I know you said you don’t want them removed and that they are useful, but why isn’t your post titled “AXIS developers don’t know how to use ThreadLocals” or something related to the _cause_ of the problem?
Dmitri,
I didn’t say
ThreadLocals are useless. I just said they should be used with caution. Of course the title is somewhat misleading, but I still think the developers that misuseThreadLocals aren’t the only problem. Sun (or whoever in charge of implementing and documenting the feature) should have documented things better and maybe restrict usage somehow! Right now it’s causing major problems and resource leaks. Even though disabling hot deployment fixes the out-of-memory errors, there still is a resource leak (it won’t cause memory usage to increase if the amount of threads doesn’t increase).[...] cts rock! ThreadLocals revisited A couple of days ago I posted a piece on ThreadLocals, using a provoking title. This post digs a little deeper and explain why OutOfMemoryErrors o [...]
[...] ThreadLocals and memory leaks revisited A couple of days ago I posted a piece on ThreadLocals, using a provoking title. This post digs a little deeper and explain why OutOfMemoryErrors o [...]
While a ThreadLocal may smell a bit like a global variable, the use of them can be neatly encapsulated. I’ll second the comment that it’s a good idea to set and unset them within a try/finally block. I’ve seen some Spring code where any attempt to set a ThreadLocal that already has a value causes an error, ensuring that failures to unset them don’t sit around long in the codebase.
[...] finished Profiling at its best: YourKit A couple of weeks ago I posted about a problem with ThreadLocals I had to hunt down. Thanks to YourKit it took me about half an hour to fi [...]
Whilst ThreadLocals have their place, they’re a disaster waiting to happen when put into WARs without proper thought. One approach is to use a wrapper which handles ThreadLocal interaction, web request setup, clean-up, and possibly persisting the ThreadLocal contents between HTTP requests by the same HttpSession. Thus people can benefit from ThreadLocals in web applications (ie being able to access an object without passing it around) without the danger. Acegi Security provides something like that in its HttpSessionContextIntegrationFilter.
I don’t think I follow though. Doesn’t the documentation state that the ThreadLocal variable is released automatically when the thread is finished?
Hi Aviad,
it’s not that if you don’t release it yourself it’ll never happen. In certain situations however this is the case. ThreadLocals are implemented using a weak hashmap and when for example the value of an entry in the map refers to the key in the map there are situations the entire entry isn’t removed.
regards,
Alef
[...] Billy Newport’s Blog Alef Arendsen’s blog Again, its perfectly ok to use ThreadLocal in your applications, but follow the initialization and cleanup rule stated above. [...]
Rega viry, deratere fac caser terfe.
Revenue share
ice Site. Could use more of these instead of the many trash blogs on the web.
Thenks, good work!
[...] In den Methoden, um die Session oder die Ttransaction zu schließen kommt ein wichtiger Aspekt hinzu: Toni machte mich auf den Artikel “ThreadLocals are EVIL!!!”aufmerksam, in dem berichtet wird, dass ThreadLocals zu MemoryLeaks führen können, da manchmal am Ende eines Threads die im ThreadLocal gespeicherten Objekte nicht gelöscht werden und sich daher akkumulieren können. Daher muss beim Schließen der Session der ThreadLocal auf jeden fall durch threadLocal.set(null) geleert werden. [...]
“I don’t think I follow though. Doesn’t the documentation state that the ThreadLocal variable is released automatically when the thread is finished?”
The thing is that threads on a server may just be returned to a thread pool so the thread never finishes and the thread locals just linger until they are reset by another request or the server is shutdown.
Using internet is simple as hell. But I can tell y ou right now, it can be very hard, if you are the first time user.
So, first thing I suggest – open the Explorer, and type in the address you like.
You’ll get there really fast, it depends on your connection speed.
Good luck.
Hi im new on here, I found this forum extremely useful & it has helped me a lot. i should be able to help out & help others like its helped me.
Sometimes i have fun [url=http://www.timesmasher.com/fguy/]watch family guy episode[/url] to helps spin abit of time.
Thx’s, See ya about.
Hoi
Ik ben op zoek naar informatie over de [url=http://www.totale-bodyscan.nl]totale body scan[/url], zit erover te denken om zo’n [url=http://www.totale-bodyscan.nl]bodyscan[/url] te laten doen.
Ik vind wel de sites van alle[url=http://www.totale-bodyscan.nl] total bodyscan[/url] aanbieders, maar die informatie lijkt me niet echt unbiased.
Heeft iemand ervaring met het doen van een[url=http://www.totale-bodyscan.nl] total body scan[/url]? Wat vond je van de [url=http://www.totale-bodyscan.nl]bodyscan[/url]? Hoe waren de resultaten?
Alle informatie is van harte welkom!
good forum buddy keep it up. [url=http://jarmlawnmower.co.cc/tires+and+tubes+for+lawn+mowers+berrytown.html]tires and tubes for lawn mowers[/url]