The following issue has been updated:
Updater: Guido Anzuoni (mailto:[EMAIL PROTECTED])
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
