cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler (JIRA)" <>
Subject [jira] Commented: (COCOON-2070) Releasing of pooled beans might skip recycle() call on aggregated beans (leading to: "Generator already set"-style exceptions)
Date Wed, 30 May 2007 06:36:15 GMT


Carsten Ziegeler commented on COCOON-2070:


I'll have a closer look at the issue and your patch today.

You're right that one should never swallow exceptions, but this is a case where an exception
should be swallowed as otherwise a malfunctioning component can bring the whole system down.
E.g. if someone has written a poor recycle() method where no null check is done for resetting
local information, this often results in NPEs from within the recycle method. And this should
not be rethrown as a runtime exception. And the second argument for ignoring the exception
is that the original Avalon pool implementation does exactly that - so we have to be compatibel

But we should log the exception and not just silently ignore it.

> Releasing of pooled beans might skip recycle() call on aggregated beans (leading to:
"Generator already set"-style exceptions)
> ------------------------------------------------------------------------------------------------------------------------------
>                 Key: COCOON-2070
>                 URL:
>             Project: Cocoon
>          Issue Type: Bug
>          Components: - Components: Sitemap
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Alexander Klimetschek
>            Assignee: Carsten Ziegeler
>            Priority: Blocker
>             Fix For: 2.2-dev (Current SVN)
>         Attachments: poolable-recycle-bug.patch
> There is a serious bug in o.a.c.core.container.spring.avalon.PoolableProxyHandler (and
PoolableFactoryBean) that can lead to exceptions like "Cannot set reader. Generator already
set". This is because the pipeline impl bean is reused from the pool, but was never recycle()d.
The recycle() call is skipped in cases when an exception is thrown by Spring inside PoolableProxyHandler.invoke("putBackIntoAvalonPool")
- this exception is simply swalled by both and PoolableFactoryBean.putIntoPool().
> The typical behaviour is that the first call to the pipeline works, but because the components
are put back into the pool unrecycled, the next call will fail. If there is lots of activity,
you might get a fresh component from the pool and it might work again, so the error seems
quite random.
> The problematic exception happens when RequestContextHolder.currentRequestAttributes()
is called when the attributes for the request are null: IllegalStateException("No thread-bound
request found:....."). The call to that method happens in the "putBackIntoAvalonPool" case
in PoolableProxyHandler.invoke(). The problem is that this code will also be called *after*
the request attributes were set to null by the RequestContextListener, because it is registered
as a destruction callback, that gets called by Spring after the attribute reset.
> The real chain of calls is as follows:
>   RequestContextListener.requestDestroyed()
>   RequestContextHolder.setRequestAttributes(null)
>   callDestructionCallbacks()
>   <- which is a destruction callback
>   PoolableFactoryBean.putIntoPool()
>   PoolableFactoryBean.enteringPool()
>   component.recycle()
>   AvalonServiceManager/Selector.release(childComponent)   <- component releases its
>   AvalonPoolable.putBackIntoAvalonPool()
>   PoolableProxyHandler.invoke()   <- intercepts the putBackIntoAvalonPool() call
>   RequestContextHolder.currentRequestAttributes()   <-- Exception !!!

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message