[JAMES-3026] OpenJPA memory leak

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.4.0
• Fix Version/s: 3.5.0
• Component/s: jpa
• Assignee: Unassigned
• Reporter: Simon Levesque
• Created: 13/Jan/20 02:41
• Updated: 21/Nov/20 18:11
• Resolved: 03/Feb/20 03:17

Description

Initially, I got this error after running for about 1.5 days:

21:53:38.455 [smtpserver-executor-82] ERROR o.a.j.p.n.BasicChannelUpstreamHandler - Unable to process request
 java.lang.OutOfMemoryError: GC overhead limit exceeded

Try #1

I added more memory with "-Xmx", but that only took a bit more hours to get out of memory.

Try #2

I checked the heap map and found:

38,405 instances of "org.apache.openjpa.kernel.FinalizingBrokerImpl", loaded by "sun.misc.Launcher$AppClassLoader @ 0x6c041ee08" occupy 1,198,987,104 (91.22%) bytes. These instances are referenced from one instance of "java.util.concurrent.ConcurrentHashMap$Node[]", loaded by "<system class loader>"
Keywords
 sun.misc.Launcher$AppClassLoader @ 0x6c041ee08
 java.util.concurrent.ConcurrentHashMap$Node[]
 org.apache.openjpa.kernel.FinalizingBrokerImpl

 
Which lead me to this article http://chathuriwimalasena.blogspot.com/2014/06/best-practices-when-using-apache.html .

In summary, before closing any connection, we should check if it contains an active transaction and roll it back.

Issue Links

• relates to: JAMES-3451 james 3.5.0 OutOfMemoryError
• links to: GitHub Pull Request #181