cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Performance with blocks protocol
Date Tue, 07 Nov 2006 09:25:09 GMT
Alexander Klimetschek skrev:
> Daniel Fagerstrom schrieb:
>> One possibility is that there is some fault in the component handling 
>> so that the block servlet component or tree processor is recreated 
>> instead of reused in some cases.
> This seems to be the real problem. There are new ResourceReader 
> instances for each request (along with the BlockSource, 
> BlockConnection etc. connected with it), but they are never reused. 
> Instead they keep in memory, referenced by some ThreadLocal storage.
> Something in the special handling o.a.c.sitemap.SitemapServlet might 
> be buggy, but we cannot see what. Do you have time to further look at 
> that this week? When using forms, the amount of data that is collected 
> this way increases so fast, that we sometimes get an OutOfMemory after 
> 3-4 reloads...
I have not done any tests yet but have looked at the code.

First The BlockServlets are configured to be singletons and created by 
the Spring container. A BlockServlet in turn creates a SitemapServlet 
(or whatever servlet type it is configured to create) in its init 
method. The Sitemap servlet creates a TreeProcessor in its init method. 
The DispatcherServlet connects to the BlockServlets in its init method. 
All components mentioned this far should AFAICS be singletons. Does this 
hold in practice in your tests?

The TreeProcessor is a singleton but it gets and populates a new 
pipeline at each request, so new ResourceReaders are supposed to be 
created. Sources are factory based so a new BlockSource is created and 
it creates in turn a new BlockConnection. All this is expected, so the 
question is if they are destroyed correctly.

Looking at the ResourceReader it is Recyclable and has a default 
max-pool-size of 32. I don't know enough about the Avalon life style 
implementation to know exactly what happens. As long as there are no 
more than 32 instances of ResourceReaders they are, AFAIU supposed to be 
kept in a pool in the memory. But we would get a problem if the recycle 
method of the ResourceReader is called to late or not at all in that 
case the other object would be kept in memory when they should have been 
garbage collected.

The BlockCallStack contains stacks in thread local memory that contain 
BlockContexts. AFAICS they don't have any references to things that 
should be garbage collected, but if they do we would have a problem.

Looking in the RequestProcessor that is called by the standard 
SitemapServlet, it calls ProcessingUtil.cleanup(), while leaving the 
processing of a request. I don't call that in the corresponding code in 
the o.a.c.sitemap.SitemapServlet, that might be a problem.

Also it would be worthwhile to scrutinize that all streams are closed as 
they should.


View raw message