A silly question: why do you use a ThreadLocal to store a constant value for entire application? why not a static variable or store into web application context , by example ?
Thanks 2011/11/23 Christopher Schultz <ch...@christopherschultz.net>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All, > > I've got a servlet that needs to log every request (potentially big > requests) to files on the disk. In order to do that in a > reasonably-tidy way, we write each file into a directory with the > current date in the path, something like this: > > .../logs/2011-11-23/request-XYX.log > > To do this, we have a SimpleDateFormat object that we use to ensure we > target the right directory. Since SimpleDateFormat isn't threadsafe, > we have two choices: synchronize or use ThreadLocal. We have opted for > the latter: ThreadLocal. > > Our servlet defines the ThreadLocal to be protected (because this is a > base class for several servlets that all do similar things) and > transient (because we just don't need it to be serialized) and > override the initialValue method, like this: > > protected transient ThreadLocal<SimpleDateFormat> dayFormat = new > ThreadLocal<SimpleDateFormat>() { > public SimpleDateFormat initialValue() > { > return new SimpleDateFormat("yyyy-MM-dd"); > } > }; > > In the servlet's destroy method, we dutifully call dayFormat.remove(). > Tomcat complains that we are leaving sloppy ThreadLocals around on > shutdown. Duh: Servlet.destroy is called by a single thread and won't > actually remove the ThreadLocal in any meaningful way. > > So, my question is whether or not there is a good way to clean-out the > ThreadLocals from our webapp? > > Given the declaration above, we are creating a new class which will be > loaded by our webapp's ClassLoader and therefore pinning that > ClassLoader in memory definitely causing a memory leak across reploy > cycles. > > One way to avoid this would be to have a library at the server-level > that only contains this simple ThreadLocat<SimpleDateFormat> > definition, but that seems like kind of an awkward solution. > > Removing the ThreadLocal after every request of course means that the > use of ThreadLocal is entirely useless. > > Should I stop worrying about the overhead of creating a > SimpleDateFormat? Should I look for a threadsafe implementation of > SimpleDateFormat (maybe in commons-lang or something)? Should I > synchronize access to the object? > > Any suggestions would be very helpful. > > Thanks, > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk7NFcAACgkQ9CaO5/Lv0PDIoACgrc5nNYGXUxjJ+hz1kWpiIL6J > SpYAoJQ6dcxCi4WmPX+1BJs9b3c+UQB5 > =3bj2 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org