[
https://issues.apache.org/jira/browse/COCOON-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski reopened COCOON-2070:
------------------------------------------
Assignee: Grzegorz Kossakowski (was: Carsten Ziegeler)
In r543066 "slightly" modified patch from Alexander has been committed but this
small modification lead to the situation that original problem has *never* been
fixed.
Line:
RequestContextHolder.currentRequestAttributes().removeAttribute(this.attributeName,
RequestAttributes.SCOPE_REQUEST);
has been *copied* to the enclosing if clause but it should has been *moved*.
See diff available at
http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableProxyHandler.java?r1=490762&r2=543066&diff_format=h
> 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.
