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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]> 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 <
> > [email protected]
> > > >
> > > 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*
> > >
> >
>
