[ 
http://issues.apache.org/jira/browse/COCOON-1574?page=comments#action_12378051 
] 

Ellis Pritchard commented on COCOON-1574:
-----------------------------------------

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

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: http://issues.apache.org/jira/browse/COCOON-1574
>      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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to