[
https://issues.apache.org/jira/browse/COCOON-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500041
]
Alexander Klimetschek commented on COCOON-2070:
-----------------------------------------------
Why shouldn't the system stop when it hits a poorly written component? If I
write a new component and make some errors in my recycle method, I want to be
notified of that, even if that means the system will crash. The container
should enforce that only valid and stable components are run. A crashing system
is the best way to force the developer to do things right - an entry in the log
will get lost, because the cocoon log is a) turned off by default (nothing to
see on the console) and b) it shows way too much information (when setting log
level to INFO).
> 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.
