[ 
https://issues.apache.org/jira/browse/COCOON-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler reassigned COCOON-2070:
----------------------------------------

    Assignee: Carsten Ziegeler

> Releasing of pooled beans might skip recycle() call on aggregated beans 
> (leading to: "Generator already set"-style exceptions)
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: COCOON-2070
>                 URL: https://issues.apache.org/jira/browse/COCOON-2070
>             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 PoolableProxyHandler.run() 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()
>   PoolableProxyHandler.run()   <- which is a destruction callback
>   PoolableFactoryBean.putIntoPool()
>   PoolableFactoryBean.enteringPool()
>   component.recycle()
>   AvalonServiceManager/Selector.release(childComponent)   <- component 
> releases its childComponent
>   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.

Reply via email to