commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From commons-...@jakarta.apache.org
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 (mailto:guido.anzuoni@kyneste.com)
       Date: Mon, 4 Oct 2004 2:10 AM
    Comment:
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
place.
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.

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

  http://issues.apache.org/jira/browse/JELLY-148?page=history

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/JELLY-148

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
 Components: 
             core / taglib.core
   Versions:
             1.0

   Assignee: 
   Reporter: Hans Gilde

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

Description:
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.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message