[jira] Commented: (COCOON-1574) Memory Leak with XMLFileModule

["Ralph Goers (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554656 ] 

Ralph Goers commented on COCOON-1574:
-------------------------------------

I have checked in XPathXMLFileModule which can be used as a replacement for XMLFileModule. It differs from XMLFileModule by
1. It caches a DocumentInfo instead of a DocumentHelper. DocumentInfo contains the Document, its Validity, the url, the resolver and the expression cache. The expression cache is a ReferenceMap containing soft references.
2. DocumentInfo objects are cached in an externally configurable cache. The default implementation uses ehcache.
3. The soruce url can contain variables which will be resolved each time the input module is used. The cache key used is the url after resolving variables.
4. Both the cacheable and reloadable parameters can be specified as variables which will be resolved each time the module is called.
5. The amount of code run in a synchronized block is much smaller.

XPathXMLFileModule performs about the same as XMLFileModule under light load. Under heavy load it experiences much more consistent behavior than XMLFileModule. In testing XMLFileModule showed a very large standard deviation in response time with a very large maximum response compared to the minimum. XPathXMLFileModule has a much smaller standard deviation and a smaller maximum response time.

> Memory Leak with XMLFileModule
> ------------------------------
>
>                 Key: COCOON-1574
>                 URL: https://issues.apache.org/jira/browse/COCOON-1574
>             Project: Cocoon
>          Issue Type: Bug
>          Components: * Cocoon Core
>    Affects 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.
-
You can reply to this email to add a comment to the issue online.