Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <29047084.1146891633123.JavaMail.jira@brutus>
Date: Sat, 6 May 2006 05:00:33 +0000 (GMT+00:00)
From: "Ralph Goers (JIRA)" <jira@apache.org>
To: dev@cocoon.apache.org
Subject: [jira] Commented: (COCOON-1574) Memory Leak with XMLFileModule
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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

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

Actually, I don't care much what is done to XMLFileModule.  I've basically decided that there are so many issues that I need fixed that I can't modify it in a backwards compatible way, so I'm writing a whole new module.  My plan is to use the store instead of a map (although it might be a new instance of the store - not sure yet).

> 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