openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <>
Subject [jira] [Commented] (OPENJPA-1193) Memory leak when using FinalizingBrokerImpl
Date Mon, 16 Jun 2014 14:56:02 GMT


Kevin Sutter commented on OPENJPA-1193:

FYI, this issue was discussed again in a recent OpenJPA forum posting:

The final result was that this user was not cleaning up their EMs when a transaction rolled
back.  Once that change was applied, the memory leak was resolved.

> Memory leak when using FinalizingBrokerImpl
> -------------------------------------------
>                 Key: OPENJPA-1193
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.2.0, 1.2.1, 2.1.1, 2.2.0
>         Environment: All environments where the finalizing broker is used
>            Reporter: David Minor
>            Assignee: Donald Woods
>             Fix For: 1.3.0
>         Attachments: fix-finalizing-broker-memory-leak.patch
> When FinalizingBrokerImpl is used, AbstractBrokerFactory uses a set backed by java's
ConcurrentHashMap to keep track of brokers, rather than a weak reference org.apache.openjpa.lib.util.concurrent.ConcurrentReferenceHashSet
as it did previously. This can lead to a memory leak if the brokers are never removed from
the Set.
> The change was originally checked in by Patrick Linskey in revision 653000 with the comment
"Improve concurrency by actively managing AbstractBrokerFactory's broker set when using non-finalizing
brokers. Credit goes to Arunabh Hazarika for identifying the bottleneck and prototyping this
> Changing the _brokers Set back to a weak reference ConcurrentReferenceHashSet fixes the
memory leak.

This message was sent by Atlassian JIRA

View raw message