[jira] [Comment Edited] (OFBIZ-5122) Memory leak due to transaction management using DBCP and MySQL

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13547765#comment-13547765 ]

Jose Manuel Vivó Arnal edited comment on OFBIZ-5122 at 1/9/13 8:52 AM:
-----------------------------------------------------------------------

Hello Jacques,

Sorry about the patch. I will prepare a new one.

This patch is just a port from the refereed in OFBIZ-2599 which should be applied to solve a DBCP memory-leak reported and solved in DBCP-294.

The main problem is:

* When a connection is created, a strong reference is stored in a _TransactionRegistry_ class, if _LocalXAConnectionFactory_ is used (as _DBCPConnectionFactory_ do).
* When this connection is removed from connection pool, _TransactionRegistry_ still contains the reference (no one remove it) and Garbage Collector can't collect it.
* So, every connection eviction the JDBC connection instances increases until a OutOfMemory is throw.

_PoolableManagedConnectionFactory_ creates a wrapper ([PoolableManagedConnection|http://svn.apache.org/viewvc/commons/proper/dbcp/branches/DBCP_1_4_x_BRANCH/src/java/org/apache/commons/dbcp/managed/PoolableManagedConnection.java?view=markup]) over each created connection instances that cleans TransactionRegistry connection reference after it is closed (into reallyClose method).

I didn't include this description because this problem was already reported in OFBIZ-2599. This issue is related to a missing [patch|https://issues.apache.org/jira/secure/attachment/12410582/patch-DBCPConneectionFactory.txt] application in resolution of that task.

Thanks.
               
      was (Author: jmvivo):
    Hello Jacques,

Sorry about the patch. I will prepare a new one for trunk and the other releases.

This patch is just a port from the refereed in OFBIZ-2599 which should be applied to solve a DBCP memory-leak reported and solved in DBCP-294.

The main problem is:

* When a connection is created, a strong reference is stored in a _TransactionRegistry_ class, if _LocalXAConnectionFactory_ is used (as _DBCPConnectionFactory_ do).
* When this connection is removed from connection pool, _TransactionRegistry_ still contains the reference (no one remove it) and Garbage Collector can't collect it.
* So, every connection eviction the JDBC connection instances increases until a OutOfMemory is throw.

_PoolableManagedConnectionFactory_ creates a wrapper ([PoolableManagedConnection|http://svn.apache.org/viewvc/commons/proper/dbcp/branches/DBCP_1_4_x_BRANCH/src/java/org/apache/commons/dbcp/managed/PoolableManagedConnection.java?view=markup]) over each created connection instances that cleans TransactionRegistry connection reference after it is closed (into reallyClose method).

I didn't include this description because this problem was already reported in OFBIZ-2599. This issue is related to a missing [patch|https://issues.apache.org/jira/secure/attachment/12410582/patch-DBCPConneectionFactory.txt] application in resolution of that task.

Thanks.
                 

> Memory leak due to transaction management using DBCP and MySQL
> --------------------------------------------------------------
>
>                 Key: OFBIZ-5122
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-5122
>             Project: OFBiz
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: SVN trunk
>         Environment: Linux, MySQL 5.5.28
>            Reporter: Jose Manuel Vivó Arnal
>            Priority: Critical
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> After several hours looking for the memory-leak, we found than the problem is the very same that OFBIZ-2599
> This issue has a patch file attached for DBCPConnectionFactory class (patch-DBCPConneectionFactory.txt) which is not applied to specified versions.
> We check that this patch solves the problem.
> Please, apply this patch.
> Thank you in advance.
> --
> Jose Manuel Vivó Arnal
> DiSiD Technologies (http://www.disid.com)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira