cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ernst Nusterer" <ernst...@gmx.at>
Subject Re: No memory leak because of Recyclable! was **Memory Leak in C2.1.4dev?
Date Thu, 15 Jan 2004 16:19:49 GMT
Dear List,

we have profiled a memoryleak in Cocoon 2.1.4, (mentioned in " **Memory Leak
in C2.1.4dev? ") , and it sounds similar to has been discussed in this
thread:

We have 2 XSP pages that call each other:

The calling page is:  
	search.xsp

which calls search-select-factory.xsp. This is done via a call to
cocoon://datasources/build-filter/n where n is a parameter and build filter gets
translated into search-select-factory.xsp by the sitemap.


search.xsp consists of:

<snip/>
	uri="cocoon://build-filter"
	// the build-filter is resolved by sitemap into search-select-factory.xsp.

	String statementSQL;
	statementSQL=XSPUtil.getSourceContents(uri, resolver);

	// now, pass statementSQL to ESQL.......

<snip/>


When we run our application for a few hours (and heavy user interaction) the
system crashes. Tomcat 4.1.18 (Windows & Linux), 256 MB of RAM.

Whe have profiled and debugged it and found that the constellation above is
causing the leak.


If I call search.xsp 10 times and profile this , we see a memory leak of
2.56 MB, 256KB per call.


If I stop tomcat after that, we see:  10 components have not been freed from
the pool.

.....
.....Cocoon is comming down...
.....
DEBUG   (2004-01-11) 17:09.20:619   [core.manager] (Unknown-URI)
Unknown-thread/DefaultComponentFactory: ComponentFactory decommissioning instance of
org.apache.cocoon.www.resources.controller.search.search_select_factory_xsp.
DEBUG   (2004-01-11) 17:09.20:619   [core.manager] (Unknown-URI)
Unknown-thread/ResourceLimitingPool: There were 4 outstanding objects when the pool was
disposed.
.....
.....Cocoon endend...

Lets look at XSPUtil.java

    // Inclusion
    public static String getSourceContents(String url, SourceResolver
resolver) throws IOException {
 
       Source source = resolver.resolveURI(url); //line 243
        try {
            return getContents(source.getInputStream()); // 245
        } finally {
            resolver.release(source);
        }
    }


Tracing in Eclipse:

a first search_select_factory_xsp Component is "got" in a method call
started at XSPUtil:243 (resolveURI), This is never freed!

Later, (in subsequent method calls started at Line 245 in XSPUtil), again a
search_select_factory_xsp  is got from the pool, but this one is freed later.
It looks like the resolveURI method starts to load the XSP page, instead of
only getting a source. This loaded page is somewhere lost, and later the page
is loaded again. It looks like that the Generators , Wrappers, etc allocated
in line 243 are never freed (no recycle is called for them).

It looks like the environment is somewhat switched, and the old environment
forgotten, but references still are alive so the GC fails to remove this. Or,
it is a bug in the resolver.resolveURI(String) method.

If we replace "cocoon://" in the example above with "http://.../", it works
without a memory leak. And in this case, resolveURI only delivers the source
to the URI, and does not leave methods in the pool.


Any help is very much appreciated.

Best regards,
Ernst

-- 
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net



Mime
View raw message