commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Updated: (JELLY-148) Huge memory leak resulting from the use of ThreadLocal
Date Mon, 04 Oct 2004 09:11:33 GMT
The following issue has been updated:

    Updater: Guido Anzuoni (
       Date: Mon, 4 Oct 2004 2:10 AM
First, my opinions are affected by my way of dealing with templates-context-transformation
in servlet env.
>From my point of view, templates are in-memory representation of (xml) files that can
safely be used concurrently by 
different threads.
Contexts are the environment in which actualisations (i.e. transformation) of templates takes
In servlet env, context is strictly related to request.
This means that a context is never reused, because of this relation.
Using a ThreadLocal to hold the "actual" incarnation of a Tag causes an implicit dependency
Context <-> Current Thread.
More, with this way of using contexts in mind, tag cleaning must be called at the beginning
of each transformation.
Looking at the way ThreadLocal hold references, it can be seen that, in an environment where
threads are resused, such a fine grain use of ThreadLocal instances leads to an uncontrollable
memory usage 
which depends on nr. of alive thread (not necessairly "active") 
and nr. of tags. More, if it is considered the way XMLParser
works, there is no easy way to add TagScript caching leading to, I think, huge gc activities.
My architectural view of the classes should allow caching of parsed ScriptBlock that will
avoid continuous xml source parsing.
For what concerns JellyContext API change, I think that it is not a big problem because the
added methods are used by TagScript, while library implementors use Tag.
Anyway, a still better solution, in my opinion, could be the one that moves userData as a
WeakHashMap into the TagScript with JellyContext as a key.
Anyway, an open issue with this approach, and the previous as well, is the behaviour
in case, for example, of a TagScript holding reference to the Tag via userData and the 
enclosing TagScript invoking run() with a child JellyContext.
In this situation the Tag instance can be found only traversing the contexts from
child to parent(s).
In jelly-nothreadlocal2.ZIP you will find an implementation of 
this approach.

Just my 2 cents.

             Attachment changed to jelly-nothreadlocal2.ZIP
For a full history of the issue, see:

View the issue:

Here is an overview of the issue:
        Key: JELLY-148
    Summary: Huge memory leak resulting from the use of ThreadLocal
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: jelly
             core / taglib.core

   Reporter: Hans Gilde

    Created: Sat, 18 Sep 2004 9:34 PM
    Updated: Mon, 4 Oct 2004 2:10 AM

There is a huge memory leak that results from the TagScript's use of ThreadLocal.

ThreadLocal is usually used from a staic variable, while TagScript uses it from an instance
variable. Although this looks legal to me, it causes a huge memory leak.

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message