Return-Path: X-Original-To: apmail-openjpa-dev-archive@www.apache.org Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BD4F4118C3 for ; Mon, 16 Jun 2014 20:54:02 +0000 (UTC) Received: (qmail 11517 invoked by uid 500); 16 Jun 2014 20:54:02 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 11429 invoked by uid 500); 16 Jun 2014 20:54:02 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 11228 invoked by uid 99); 16 Jun 2014 20:54:02 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jun 2014 20:54:02 +0000 Date: Mon, 16 Jun 2014 20:54:01 +0000 (UTC) From: "Kevin Sutter (JIRA)" To: dev@openjpa.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (OPENJPA-1193) Memory leak when using FinalizingBrokerImpl MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/OPENJPA-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032500#comment-14032500 ] Kevin Sutter edited comment on OPENJPA-1193 at 6/16/14 8:52 PM: ---------------------------------------------------------------- FYI, this issue was discussed again in a recent OpenJPA forum posting: http://openjpa.208410.n2.nabble.com/Is-there-a-memory-leak-with-org-apache-openjpa-kernel-FinalizingBrokerImpl-tc7586744.html#a7586804 The final result was that this user was not cleaning up their transactions on error conditions (ie. mark the transaction for rollback). Once that change was applied, the memory leak was resolved. was (Author: kwsutter): FYI, this issue was discussed again in a recent OpenJPA forum posting: http://openjpa.208410.n2.nabble.com/Is-there-a-memory-leak-with-org-apache-openjpa-kernel-FinalizingBrokerImpl-tc7586744.html#a7586804 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: https://issues.apache.org/jira/browse/OPENJPA-1193 > 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 solution." > Changing the _brokers Set back to a weak reference ConcurrentReferenceHashSet fixes the memory leak. -- This message was sent by Atlassian JIRA (v6.2#6252)