commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Commented: (JELLY-148) Huge memory leak resulting from the use of ThreadLocal
Date Mon, 20 Sep 2004 11:28:38 GMT
The following comment has been added to this issue:

     Author: Guido Anzuoni
    Created: Mon, 20 Sep 2004 4:28 AM
If Tag could represent an "incarnated" TagScript wrt a JellyContext
than the various incarnations of the Script should be cached
int the context itself rather than in a ThreadLocal.
Adding a simple Map in JellyContext with TagScript as key
will solve all memory leaks with no impact.
Here follows the outline of changes.

JellyContext {

public Object getTagScriptData(TagScript t);
public void setTagScriptData(TagScript t, Object d);


TagScript {
public Tag getTag(JellyContext ctx) throws JellyException {
  TagScriptContextualData tscd = 
    (TagScriptContextualData) ctx.getTagScriptData(this);
  if (tscd == null) {
     tscd = new TagScriptContextualData();
     ctx.setTagScriptData(this, tscd);
  Tag tag = tscd.getTag();
  if (tag == null) {
     tag = createTag();

}// end of public Tag getTag()


public void run(JellyContext context, XMLOutput output) 
             throws JellyTagException {
        try {
            Tag tag = getTag(context);
            if ( tag == null ) {

            if ( tag instanceof DynaTag ) {
}// end of public void run()



View this comment:

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, 20 Sep 2004 4:28 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