cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Trieloff <>
Subject Re: Performance with blocks protocol
Date Tue, 07 Nov 2006 19:29:17 GMT

we should check that there are really no more than 32 instances of  
ResourceReader on the heap. If this is the case, all we need to do is  
to raise the -Xmx limit and add a note to the docs that blocks might  
need some more memory.

Meanwhile I will try to reproduce this problem in the cocoon-blocks- 
fw-demo so that it can be tested using JMeter and YourKit Java Profiler.


Am 07.11.2006 um 10:25 schrieb Daniel Fagerstrom:

> Alexander Klimetschek skrev:
>> 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...
> 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.

Lars Trieloff

View raw message