[
https://issues.apache.org/jira/browse/COCOON-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500039
]
Carsten Ziegeler commented on COCOON-2070:
------------------------------------------
Hi,
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: 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.
