[jira] Closed: (COCOON-2070) Releasing of pooled beans might skip recycle() call on aggregated beans (leading to: Generator already set-style exceptions)
[ 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.
[jira] Closed: (COCOON-2070) Releasing of pooled beans might skip recycle() call on aggregated beans (leading to: Generator already set-style exceptions)
[ https://issues.apache.org/jira/browse/COCOON-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON-2070. Resolution: Fixed I committed a slightly modified versin of your patch wrt to exception handling and logging. Many thanks for the patch. Please cross-check and then close this bug. Thanks! 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.
