Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (nike.apache.org: domain of kamalasini@gmail.com designates
 209.85.217.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABFJMzNzD2JUpnGCv4xZfc+Cci8ZjXMXzgYM9FV0QS--KkfSFg@mail.gmail.com>
References: 
 <CABFJMzOLKwO7g62dusg5yAZ67Ad+cuk53kOzoKVxOO3vPeX4dQ@mail.gmail.com>
 <CAP=qHCvrdtVuUxxczqbAfBn4aWk+y7t60Lowx-fzZff6cJV0AA@mail.gmail.com>
 <CABFJMzOj38P4FUKkV0YcFv7JxHz4JXo27neV_wiGFpsMBufn5w@mail.gmail.com>
 <CABH8er=Zod6xQQOKY95wK0ALJUFUp=384V8C-8hRnnoADysdZg@mail.gmail.com>
 <CABFJMzNzD2JUpnGCv4xZfc+Cci8ZjXMXzgYM9FV0QS--KkfSFg@mail.gmail.com>
From: Chathuri Wimalasena <kamalasini@gmail.com>
Date: Fri, 6 Jun 2014 10:05:33 -0400
Message-ID: 
 <CABFJMzOcAWCNj7YOYJmxSZgV4f_kBu12w9zQLciCzWremcx1yg@mail.gmail.com>
Subject: Re: Is there a memory leak with
 org.apache.openjpa.kernel.FinalizingBrokerImpl
To: dev@openjpa.apache.org
Content-Type: multipart/alternative; boundary=14dae93d93801b77a404fb2b5cf9

--14dae93d93801b77a404fb2b5cf9
Content-Type: text/plain; charset=UTF-8

Appreciate someone's insight on this issue.

Thanks..
Chathuri


On Tue, Jun 3, 2014 at 12:22 PM, Chathuri Wimalasena <kamalasini@gmail.com>
wrote:

> Hi,
>
> Thanks for the responses. I checked almost all the places where we are
> using entityManager instance and make sure they are closed after they have
> been used.
>
> Here are the two suspect classes I'm getting when analysing the memory
> dump.
>
> *Problem Suspect 1*
>
> 546,326 instances of *"org.apache.openjpa.kernel.FinalizingBrokerImpl"*,
> loaded by *"sun.misc.Launcher$AppClassLoader @ 0x7007c7bc0"* occupy *1,031,525,848
> (56.39%)* bytes. These instances are referenced from one instance of
> *"java.util.concurrent.ConcurrentHashMap$Segment[]"*, loaded by *"<system
> class loader>"*
>
> *Keywords*
> java.util.concurrent.ConcurrentHashMap$Segment[]
> sun.misc.Launcher$AppClassLoader @ 0x7007c7bc0
> org.apache.openjpa.kernel.FinalizingBrokerImpl
>
>
> *Problem Suspect 2*
>
> 546,300 instances of *"org.apache.openjpa.kernel.LocalManagedRuntime"*,
> loaded by *"sun.misc.Launcher$AppClassLoader @ 0x7007c7bc0"* occupy *680,034,240
> (37.17%)* bytes. These instances are referenced from one instance of
> *"java.util.concurrent.ConcurrentHashMap$Segment[]"*, loaded by *"<system
> class loader>"*
>
> *Keywords*
> java.util.concurrent.ConcurrentHashMap$Segment[]
> sun.misc.Launcher$AppClassLoader @ 0x7007c7bc0
> org.apache.openjpa.kernel.LocalManagedRuntime
>
> This is how we create the Entity manager instance.
>  public static EntityManager getEntityManager(){
>         if (factory == null) {
>             String connectionProperties = "DriverClassName=" +
> Utils.getJDBCDriver() + "," + "Url=" +
>               Utils.getJDBCURL() + "," +"Username=" + Utils.getJDBCUser() +
> "," +                                           "Password=" +
> Utils.getJDBCPassword() + ",validationQuery=" +
>                     Utils.getValidationQuery() + "," +
>
> Utils.getJPAConnectionProperties();
>             Map<String, String> properties = new HashMap<String, String>();
>             properties.put("openjpa.ConnectionDriverName",
> "org.apache.commons.dbcp.BasicDataSource");\
>             properties.put("openjpa.ConnectionProperties",
> connectionProperties);
>             properties.put("openjpa.DynamicEnhancementAgent", "true");
>             properties.put("openjpa.RuntimeUnenhancedClasses",
> "unsupported");
>             properties.put("openjpa.DataCache","true(CacheSize=5000,
> SoftReferenceSize=0)");
>             properties.put("openjpa.QueryCache","true(CacheSize=5000,
> SoftReferenceSize=0)");
>             properties.put("openjpa.RemoteCommitProvider","sjvm");
>             properties.put("openjpa.Log","DefaultLevel=INFO, Runtime=INFO,
> Tool=INFO, SQL=INFO");
>             properties.put("openjpa.jdbc.SynchronizeMappings",
> "buildSchema(ForeignKeys=true)");
>             properties.put("openjpa.jdbc.QuerySQLCache", "false");
>
>             factory =
> Persistence.createEntityManagerFactory(PERSISTENCE_UNIT_NAME, properties);
>         }
>        return factory.createEntityManager();
>     }
>
> This is how we use entityManager and close it.
> public void save() throws RegistryException {
>         EntityManager em = null;
>         try {
>             em = ResourceUtils.getEntityManager();
>             Gateway existingGateway = em.find(Gateway.class, gatewayName);
>             em.close();
>
>             em = ResourceUtils.getEntityManager();
>             em.getTransaction().begin();
>             Gateway gateway = new Gateway();
>             gateway.setGateway_name(gatewayName);
>             gateway.setOwner(owner);
>             if (existingGateway != null) {
>                 existingGateway.setOwner(owner);
>                 gateway = em.merge(existingGateway);
>             } else {
>                 em.persist(gateway);
>             }
>             em.getTransaction().commit();
>             em.close();
>         } catch (Exception e) {
>             logger.error(e.getMessage(), e);
>             throw new RegistryException(e);
>         } finally {
>             if (em != null && em.isOpen()) {
>                 em.close();
>             }
>         }
>     }
>
> Do you see any issues with this implementation ?
>
>
> Thanks..
> Chathuri
>
>
> On Mon, Jun 2, 2014 at 6:52 PM, Kevin Sutter <kwsutter@gmail.com> wrote:
>
>> The scary part of the proposed patch is what impact this will have on the
>> "more important" non-finalizing BrokerImpl...  That is, if these two
>> assignments would get reversed now to correct this supposed memory leak
>> with FinalizingBrokerImpl, what impact would this have on non-finalizing
>> BrokerImpls?
>>
>>         if
>>
>> (FinalizingBrokerImpl.class.isAssignableFrom(bv.getTemplateBrokerType(_conf)))
>> {
>>             return MapBackedSet.decorate(new ConcurrentHashMap(), new
>> Object() { });
>>         } else {
>>             return new
>> ConcurrentReferenceHashSet<Broker>(ConcurrentReferenceHashSet.WEAK);
>>         }
>>
>> I mean "more important" since in most cases we want the container to
>> manage
>> the lifecycle and, thus, avoid the overhead associated with the
>> FinalizingBrokerImpl...
>>
>>
>>
>> On Mon, Jun 2, 2014 at 1:26 PM, Chathuri Wimalasena <kamalasini@gmail.com
>> >
>> wrote:
>>
>> > I'm closing all the EntityManagers in a finally block. I will check if I
>> > miss any place.
>> >
>> >
>> > On Mon, Jun 2, 2014 at 2:17 PM, Rick Curtis <curtisr7@gmail.com> wrote:
>> >
>> > > > Any idea why I might get this issue and any suggestions to avoid
>> this ?
>> > > Please make sure that your application closes all EntityManagers when
>> > > you're through with them.
>> > >
>> > > Thanks,
>> > > Rick
>> > >
>> > >
>> > > On Mon, Jun 2, 2014 at 12:20 PM, Chathuri Wimalasena <
>> > kamalasini@gmail.com
>> > > >
>> > > wrote:
>> > >
>> > > > Hi Devs,
>> > > >
>> > > > We are using apache openJPA 2.2 version and we experience some
>> memory
>> > > leak
>> > > > issues. While analyzing the memory dump, I see
>> > > > *org.apache.openjpa.kernel.FinalizingBrokerImpl
>> > > > *as one suspect for the memory leak.
>> > > >
>> > > > 311,437 instances of
>> > *"org.apache.openjpa.kernel.FinalizingBrokerImpl"*,
>> > > > loaded by *"sun.misc.Launcher$AppClassLoader @ 0x117a09088"* occupy
>> > > > *585,849,792
>> > > > (55.60%)* bytes. These instances are referenced from one instance of
>> > > > *"java.util.concurrent.ConcurrentHashMap$Segment[]"*, loaded by
>> > *"<system
>> > > > class loader>"*
>> > > >
>> > > > *Keywords*
>> > > > java.util.concurrent.ConcurrentHashMap$Segment[]
>> > > > sun.misc.Launcher$AppClassLoader @ 0x117a09088
>> > > > org.apache.openjpa.kernel.FinalizingBrokerImpl
>> > > >
>> > > > While searching, I found [1] which is still open. Does this patch
>> > applied
>> > > > in openJPA 2.2 version ? Any idea why I might get this issue and any
>> > > > suggestions to avoid this ?
>> > > >
>> > > > Thanks..
>> > > > Chathuri
>> > > >
>> > > > [1] https://issues.apache.org/jira/browse/OPENJPA-1193
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > *Rick Curtis*
>> > >
>> >
>>
>
>

--14dae93d93801b77a404fb2b5cf9--