Volker Schmitt wrote:
> >
> > > The last days showed that we have a lot of potential memory leaks,
> > > see
> > >
> > > [1] http://marc.theaimsgroup.com/?t=107330680600002&r=1&w=2
> > > and
> > >
> > > [2] http://marc.theaimsgroup.com/?t=107355695400003&r=1&w=2
> > >
> > > This is caused by the simple fact that in some cases the recycle()
> > > method of a Recyclable component is not called (see [2] for some
> > > details about that).
> >
> > Hm, If I look to the ECM code (ResourceLimitingPool):
> >
> > /**
> > * Returns a poolable to the pool and notifies any thread blocking.
> > *
> > * @param poolable Poolable to return to the pool.
> > */
> > public void put( Poolable poolable )
> > {
> > // Handle Recyclable objects
> > if( poolable instanceof Recyclable )
> > {
> > ( (Recyclable)poolable ).recycle();
> > }
> > synchronized( m_semaphore )
> > {
> >
> >
> > it can' t be the case (for ECM) that a component is not recycled,
because
> > calling recycle is done before checking the pool full condition. I
agree,
> > that this is not a defined behavior and can be container dependent.
> >
> Hmm, Berin did say that Recyclabe is in our case not called. The
component
> is not in the pool, so can it be that in that case even put() isn't
called?
> (I don't have time to verify this in the source code today)
>
> Carsten
This can't be the case, because the PoolableComponentHandler directly
delegates this to the ResourceLimitingPool. So this means, that recycle is
called every time a pooled component is released. But only if the
ComponentHandler is found.
The code:
/**
* Return a reference of the desired Component
*/
protected void doPut( final Component component )
{
if( !m_initialized )
{
throw new IllegalStateException( "You cannot put a component in " +
"an uninitialized holder." );
}
m_pool.put( (Poolable)component );
}
What I can say, about Memory leak, that our eCommerce portal
https://worldaccount.basf.com/wa/Startpage
has no problems with leaks, since we fixed the ComponentManagerProxy
problem in ECM. See Thread "[IMP] Performance Killer and Memory leak". We
have 6000 Http-request/hour and the memory usage doesn't increase over
time. I think this fix is not part of the latest stable build. I think the
same is true for
http://archives.real-time.com/pipermail/cocoon-devel/2003-November/022744.html
Volker
