cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Re: No memory leak because of Recyclable!
Date Tue, 13 Jan 2004 10:56:26 GMT
Volker Schmitt wrote:
> 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. >
> 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.
>
Now, after looking at the code, I seems that there are problems with the
bucket map. Apart from that everything seems ok.

I'm a little bit concerned, that the ECM Selector uses a
component.toString()
as a unique identifier among all components. Why is not the component itself
used? This fails as soon as a component overwrites toString(). In the
case of the CachingPP toString is not overwritten. So this shouldn't be
a problem here.

Now, we could recycle/dispose a component when the handler is not found in
the selector as a workaround. This would at least solve the memory leak
but of course not the real problem.

Carsten



Mime
View raw message