On 31/08/2010 11:30, Jess Holle wrote: > On 8/31/2010 4:03 AM, Leon Rosenberg wrote: >> On Tue, Aug 31, 2010 at 10:51 AM, Ognjen Blagojevic >> <ognjen.d.blagoje...@gmail.com> wrote: >>>>>> Is there no way for me to kill these? >>>>> Not easily. Most uses of ThreadLocal seem to be blissfully (sometimes >>>>> arrogantly) unaware of thread-pooling mechanisms and app servers. >>>>> Ideally, >>>>> these ThreadLocal instances would instead be created in a pool for the >>>>> webapp to use, rather than being tied to individual threads. >>>> 6.0.26 removes those by default. 6.0.29, removing them is optional - >>>> see >>>> the clearReferencesThreadLocals attribute on the context. >>>> >>>> The only way to get rid of the messages is to fix the memory leak. >>> Other solution is to create a new thread by yourself and delegate the >>> iCal4j >>> work to it. Once the thread is finished, ThreadLocal variables are also >>> released. We managed to work around similar leak in older JasperReports >>> library like that. >>> >>> Be aware, however, that creation of threads takes some resources, and >>> that >>> you should take necessary steps to clean up those threads in all >>> cases (when >>> exception is thrown in the thread, or when the server shuts down >>> while your >>> thread is still active).
>> The more I think about the issue, the more I feel that this is a bug >> in the container which defines two different lifecycles one for >> >> webapps and one for threads which use the webapps, nd, in case of >> ThreadLocal, contain the webapp code. As a library developer I can not >> be aware that I'm running in a container and how this particular >> container defines its and my lifecycles. Providing a >> ServletContextListener for each container along with my small logging >> library (example) seems a little overkill. I disagree. It doesn't matter whether you're in a container or not, you should always clean up after yourself. >> The cleanest solution would be to either have an executor service per >> webapp (which will be tricky to become effective) or to replace all >> threads in the thread pool >> on redeploy. Correct me if I'm wrong, but hot-redeploy isn't meant as >> production system feature anyway (at least it wasn't time ago), and >> the performance impact for >> thread pool renewal on a staging system is negligible. > While I think it would be *nice* of a container to replace threads on a > web app redeploy/restart, I wouldn't go so far as to say that not doing > so is a bug. Do OSGi containers raise similar issues with module > redeployment? I'd guess so -- and guess that replacing threads might be > harder in such cases. > > That said, replacing threads in a web app container seems fairly > straightforward and seems like a more friendly approach than telling > library authors to rework their code or trying to remove thread locals > in a non-thread-safe fashion. Only with an Executor is it possible to remove threads from the pool, in 6+ AFAIK. The Executor does not currently listen to events from the Context, ie redeployment. The solution I was/am exploring is to compare creation times of threads and webapps, and replace the thread if it's older than the webapp, rather than recreate the entire ThreadPool in one go. This could occur incrementally during usage, or via a pool sweeper. p > -- > Jess Holle > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
0x62590808.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
