cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ellis Pritchard (JIRA)" <>
Subject [jira] Commented: (COCOON-1574) Memory Leak with XMLFileModule
Date Fri, 05 May 2006 15:14:29 GMT
    [ ] 

Ellis Pritchard commented on COCOON-1574:

That's great; I'd noticed the ever-growing-cache problem, but not the synchronization problem,

On the users mailing list, dynamic configuration was mentioned, i.e. adding the URI of the
XML file to the string used by the module (name parameter to getAttribute()), Andrew Stevens
suggested using XPointer notation:

e.g. you could do <map:parameter name="foo" value="{myxmlfile:{1}.xml#xpointer(/document/bar/foo)}"/>

Is this something you could include in the new version?

> Memory Leak with XMLFileModule
> ------------------------------
>          Key: COCOON-1574
>          URL:
>      Project: Cocoon
>         Type: Bug

>   Components: * Cocoon Core
>     Versions: 2.2-dev (Current SVN)
>  Environment: Operating System: Windows XP
> Platform: PC
>     Reporter: Ron Blaschke
>     Assignee: Ralph Goers

> I'm currently looking into a memory leak issue at Apache Forrest.  Forrest's
> site currently needs to be built with -Xmx128m because of this.  I believe the
> issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule.
> A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which
> get referenced by XMLFileModule.DocumentHelper.  Their URIs are linkmap-xxx.
> LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper,
> which seems to reference a XMLFileModule.
>   ...
>   newLink = (String) modHelper.getAttribute(this.objectModel,
>                      ^^^^^^^^^
>   ...
> The XMLFileModule keeps the visited documents in a map, which is where they
> build up.
> Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from
>   this.documents.put(src, new DocumentHelper(reload, cache, src, this));
> to
>   return new DocumentHelper(reload, cache, src, this);
> Thus, a new DocumentHelper is created every time, instead of caching them.  The
> result: No more memory problems, Apache Forrest's site builds again with -Xmx32.
> Ron

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message