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
