Hi,
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.
Lars
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
visit http://www.mindquarry.com/
