Simon Levesque created JAMES-3026:
-------------------------------------
Summary: OpenJPA memory leak
Key: JAMES-3026
URL: https://issues.apache.org/jira/browse/JAMES-3026
Project: James Server
Issue Type: Bug
Components: jpa
Affects Versions: 3.4.0
Reporter: Simon Levesque
Initially, I got this error after running for about 1.5 days:
{noformat}
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{noformat}
h1. Try #1
I added more memory with "-Xmx", but that only took a bit more hours to get out
of memory.
h1. Try #2
I checked the heap map and found:
{noformat}
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
{noformat}
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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
