IBM Support

OutOfMemory caused by Leak in Open JPA

Troubleshooting


Problem

After using an application for some time you will begin to see slowness in the application and eventually you will see an OutOfMemory exception in the systemOut.log file for the WebSphere Application Server.

Symptom

OutOfMemory in the SystemOut.log and or seeing in the heap dump analysis tool:


632,175,672 (79.22%) [32] 20 class                            
org/apache/openjpa/enhance/PCEnhancer 0xa570f250                        
 632,174,752 (79.22%) [32] 6 class org/apache/openjpa/enhance/PCRegistry
0xa57200e0                                                              
  632,170,336 (79.22%) [24] 1 java/util/LinkedList 0xa57cd600

Message in the trace file for JPA.

Cause

The problem arises with applications that do not use injection (ie, @PersistenceContext or @PersistenceUnit) to obtain JPA resources. Instead, the applications use javax.persistence.Persistence.getEntityManagerFactory(). While this is not forbidden, it is not a good practice. The reason that it is not a good practice is that the application developer is the one responsible for closing the EMF once it is no longer necessary. Garbage collecting an EMF does not automatically close it. There is no Finalizer that will do that for the application. Another reason that this is not a good practice is because creating a EMF is an expensive process, a better performing application will create and cache an EMF (pretty much automatically done if you use injection), and use the cached EMF to create an EntityManager (EM) and dispose of it once the transaction is complete.

So if an application creates an EMF via Persistence.createEMF() and does not close it, you will get the above leak. This is because the PCRegistry (before the OJ-2042 alteration) maintained a strong reference to the listener data structure. This link is removed only when an EMF is properly closed. So when EMFs are GC'd without being properly closed, the refs to these data structures will accumulate until the heap is exhausted.

This has been the case for 100% of the above signature.

Diagnosing The Problem

When using the IBM Heap Dump Analyzer you will see something like the following.



Since this is an OOM problem, it seems likely that this is something in the JVM initially, so you will get Java cores/dumps and see entries like the one above.

When reviewing the java cores/dumps with the Heap Analyzer Tool , the following leak suspect will surface for this issue:

632,175,672 (79.22%) [32] 20 class
org/apache/openjpa/enhance/PCEnhancer 0xa570f250
632,174,752 (79.22%) [32] 6 class org/apache/openjpa/enhance/PCRegistry
0xa57200e0
632,170,336 (79.22%) [24] 1 java/util/LinkedList 0xa57cd600

Look at the dump above. You see PCRegistry, a class from OpenJPA, occupying a significant chunk of the heap (79% in this case). Virtually all of that heap is retained by its LinkedList member - that linked list is a list of Listeners (where a listener is a data structure that is a one-to-one mapping with an EntityManagerFactory (EMF) - if that data structure is part of the EMF instance.)

The above is the key signature of OPENJPA-2042:

Resolving The Problem

Use injection (ie @PersistenceContext or @PersistenceUnit) to obtain JPA resources rather than the above or the fix provided by OJ-2042 (delivered by PM64489 and PM64591) works around this issue by changing the PCRegistry's reference to the listening data structure from a strong to weak reference. This allows the application server to tolerate the fact that these EMFs are not getting properly closed.

[{"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Java Persistence API (JPA)","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"9.0;8.5;8.0;7.0","Edition":"Base;Feature Pack for EJB 3.0;Network Deployment","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
15 June 2018

UID

swg21617421