> [EMAIL PROTECTED] wrote:
> > Ok, to be sure, if there is now a memory leak with Recyclable
components in
> > some cases, I did a simple test case:
> > Setting the maximum pool of a Recyclable component to 2, lookup ten
> > instances in a row and release them.
> >
> > Now, guess what happens?
> > All ten instances get recycle() called and 8 instances get as well
dispose()
> > called.
> >
> > So, although the theory is, that we can't rely on recycle() being
called
> > always, it's currently the case with ECM!
> >
> > However, I think we should keep this in mind and change the code that
we
> > don't rely on this.
> Then the real problem here is that the leak is coming from the fact that
under
> heavy enough load, the HashMaps are not returning the reference to the
> ComponentHandler to return the component to the pool.
yes, the problem is following situation:
WARN (2004-01-06) 17:19.49:453 [sitemap] (/vsky/index.preg)
wap-4/ExcaliburComponentSelector: Attempted to release a org.apache.coc
oon.components.pipeline.impl.CachingProcessingPipeline but its handler
could
not be located.
This mean, that the CachingProcessingPipeline can't be released because the
ComponentHandler can't be located. This means, that for this
CachingProcessingPipeline the recycle method is not called. If you look to
the recycle method you found:
Recycle method of BaseCachingProcessingPipeline:
/**
* Recyclable Interface
*/
public void recycle() {
this.manager.release( this.xmlDeserializer );
this.xmlDeserializer = null;
this.manager.release( this.xmlSerializer );
this.xmlSerializer = null;
super.recycle();
}
If you now look to the result of the profiling, see Thread
**Memory Leak in C2.1.4dev? (was: RE: AW: Cocoon 2.1.3 breakdown when load
testing)**
<result>
After that we made another snapshot with P1, P2 and 8 iterations of P3. And
when we looked to the heap again the obvious thing was that 8 new byte[] of
about 256 KB each where now on the heap. This correlated to our measures
that
the heap grew 2M for 8 iterations.
</result>
the reason of the byte[] leak is the unreleased Serializer/Deserializer.
The challence is now to found the reason why the CachingProcessingPipeline
can't be released. We had a similar problem with our application, see
Thread:
http://archives.real-time.com/pipermail/cocoon-devel/2003-November/022744.html
but this problem is fixed in 2.1.3.
Volker
