cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COCOON-1574) Memory Leak with XMLFileModule
Date Fri, 28 Dec 2007 05:18:43 GMT

    [ 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.


Mime
View raw message