[
https://issues.apache.org/jira/browse/COCOON-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski closed COCOON-2070.
----------------------------------------
Resolution: Fixed
Affects version (Component): Parent values: Components: Sitemap(10152).
Level 1 values: 1.0.0-RC3-dev(10312).
Fix version (Component): Parent values: Components: Sitemap(10229).
Level 1 values: 1.0.0-RC3-dev(10306).
Fixed *definitively* in r639686. Thanks again Alexander for your patch!
> 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: Grzegorz Kossakowski
> 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.
