[jira] [Updated] (COCOON-2259) Memory leak in PoolableProxyHandler

2012-08-06 Thread Thorsten Scherler (JIRA)

 [ 
https://issues.apache.org/jira/browse/COCOON-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Scherler updated COCOON-2259:
--

Assignee: Thorsten Scherler  (was: Jasha Joachimsthal)

> Memory leak in PoolableProxyHandler
> ---
>
> Key: COCOON-2259
> URL: https://issues.apache.org/jira/browse/COCOON-2259
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.2, 2.2-dev (Current SVN)
>Reporter: Alexander Daniel
>Assignee: Thorsten Scherler
> Fix For: 2.2-dev (Current SVN)
>
> Attachments: patchForIssue2259.txt
>
>
> I reproduced the problem with following pipeline and by adding log output to 
> PoolableProxyHandler [1]
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
> Changing the line 
>  this.attributeName = PoolableProxyHandler.class.getName() + '/' + 
> this.handler.hashCode();
> to
>  this.attributeName = PoolableProxyHandler.class.getName() + '/' + 
> this.hashCode();
> fixes the memory leak.
> Why? The PoolableFactoryBean [2] handler is a singleton for every pipeline 
> component, i.e. one instance for noncaching pipeline, one instance for xalan 
> transformer, ... Therefore the attributeName is the same for every component 
> of the same type but Spring requires an unique value for the destruction 
> callback handler.
> In the example sitemap above two noncaching pipeline instances are needed for 
> processing the request. Both call registerDestructionCallback with the same 
> attributeName. Because the attributeName is the same the callback is only 
> called once and the other component remains in ThreadLocal.
> [1] 
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableProxyHandler.java
> [2] 
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (COCOON-2259) Memory leak in PoolableProxyHandler

2009-07-07 Thread Alexander Daniel (JIRA)

 [ 
https://issues.apache.org/jira/browse/COCOON-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Daniel updated COCOON-2259:
-

Other Info: [Patch available]

> Memory leak in PoolableProxyHandler
> ---
>
> Key: COCOON-2259
> URL: https://issues.apache.org/jira/browse/COCOON-2259
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.2, 2.2-dev (Current SVN)
>Reporter: Alexander Daniel
> Attachments: patchForIssue2259.txt
>
>
> I reproduced the problem with following pipeline and by adding log output to 
> PoolableProxyHandler [1]
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
> Changing the line 
>  this.attributeName = PoolableProxyHandler.class.getName() + '/' + 
> this.handler.hashCode();
> to
>  this.attributeName = PoolableProxyHandler.class.getName() + '/' + 
> this.hashCode();
> fixes the memory leak.
> Why? The PoolableFactoryBean [2] handler is a singleton for every pipeline 
> component, i.e. one instance for noncaching pipeline, one instance for xalan 
> transformer, ... Therefore the attributeName is the same for every component 
> of the same type but Spring requires an unique value for the destruction 
> callback handler.
> In the example sitemap above two noncaching pipeline instances are needed for 
> processing the request. Both call registerDestructionCallback with the same 
> attributeName. Because the attributeName is the same the callback is only 
> called once and the other component remains in ThreadLocal.
> [1] 
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableProxyHandler.java
> [2] 
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (COCOON-2259) Memory leak in PoolableProxyHandler

2009-07-03 Thread Alexander Daniel (JIRA)

 [ 
https://issues.apache.org/jira/browse/COCOON-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Daniel updated COCOON-2259:
-

Attachment: patchForIssue2259.txt

The patch includes the fix described in the description and additional logging 
for PoolableProxyHandler.

Patch was created against Cocoon 2.2 trunk. Use patch -p0 
 Memory leak in PoolableProxyHandler
> ---
>
> Key: COCOON-2259
> URL: https://issues.apache.org/jira/browse/COCOON-2259
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.2, 2.2-dev (Current SVN)
>Reporter: Alexander Daniel
> Attachments: patchForIssue2259.txt
>
>
> I reproduced the problem with following pipeline and by adding log output to 
> PoolableProxyHandler [1]
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
> Changing the line 
>  this.attributeName = PoolableProxyHandler.class.getName() + '/' + 
> this.handler.hashCode();
> to
>  this.attributeName = PoolableProxyHandler.class.getName() + '/' + 
> this.hashCode();
> fixes the memory leak.
> Why? The PoolableFactoryBean [2] handler is a singleton for every pipeline 
> component, i.e. one instance for noncaching pipeline, one instance for xalan 
> transformer, ... Therefore the attributeName is the same for every component 
> of the same type but Spring requires an unique value for the destruction 
> callback handler.
> In the example sitemap above two noncaching pipeline instances are needed for 
> processing the request. Both call registerDestructionCallback with the same 
> attributeName. Because the attributeName is the same the callback is only 
> called once and the other component remains in ThreadLocal.
> [1] 
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableProxyHandler.java
> [2] 
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.