Interesting! Looking at this JIRA, it looks like the proposed change was put into 1.3.0 and tentatively put into the 2.0 stream. But, then it was backed out to some performance concern...
Any chance you could run with this patch and see if it helps with your memory leak? As Patrick indicated in the nabble post, the use of FinalizingBrokerImpl is a "stop gap" measure. But, if you must run with it, then we should try to identify the source of the memory leak and resolve it. Kevin 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 >
