[ http://issues.apache.org/jira/browse/COCOON-1574?page=all ]
Ralph Goers updated COCOON-1574:
--------------------------------
Bugzilla Id: (was: 36162)
Component: * Cocoon Core
(was: Blocks: (Undefined))
Description:
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
was:
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
> 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: Cocoon Developers Team
>
> 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
