Jim - I'm not going to claim to know this audit code, but it looks like there is an OpenJPA bug. I think the problem is that in AuditManager<eclipse-javadoc:%E2%98%82=openjpa-kernel/src%5C/main%5C/java%3Corg.apache.openjpa.kernel%7BAuditManager.java%E2%98%83AuditManager>.afterBegin(...) we register a listener (Broker.addLifecycleListener), but we fail to deregister this listener. FYI -- I'm out on vacation from 8/16 - 9/3.
-------------------------------------------------------------------------------------------------------------- Class Name | Shallow Heap | Retained Heap | Percentage -------------------------------------------------------------------------------------------------------------- org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl @ 0x74142b8c0 | 520 | 84,080,184 | 66.72% |- org.apache.openjpa.lib.conf.PluginValue @ 0x741455100 | 72 | 83,620,760 | 66.36% | |- org.apache.openjpa.event.LifecycleEventManager @ 0x741bfba38| 40 | 83,620,576 | 66.36% | | |- java.util.HashMap @ 0x741c0fab0 | 48 | 83,620,392 | 66.36% | | | '- java.util.HashMap$Entry[16] @ 0x741c22a28 | 80 | 83,620,344 | 66.36% -------------------------------------------------------------------------------------------------------------- ... and there are 10K entries in this map. Thanks, Rick ------- Thanks, Rick On Wed, Aug 8, 2012 at 2:36 AM, Jim Talbut <jtal...@spudsoft.co.uk> wrote: > Rick, > > I've put the file on dropbox and shared it with you - if anyone else wants > access just let me know (today if possible). > I've also put a few relevant Java files there to. > If you'd like me to put the files somewhere else just let me know where. > > I removed the @Auditable attribute from the large entities and my memory > problems went away, so it does seem to be audit related. > > If I'm reading the file correctly there are 108 instances of > Document_JpaImpl (there were never that many rows in the database). > The entities don't have an id value yet, but they do relate to a parent > assessmentResults entity (and there is a one-to-one relationship in > practice, though in theory the parent could have multiple children). > The documents #2-#52 all relate to assessmentResults #73, so I'm thinking > they are duplicates. > > The byte arrays may be large enough to have been created in the tenured > generation - I don't know if that's upsetting things somehow (a full > garbage collection doesn't get rid of them). > > I'm on holiday as of now and won't be responding to any emails after today > until 18 August, so please don't take silence as a lack of interest. > I am very keen to get to the bottom of this and will respond when I get > back, and will provide whatever information you need to identify the > problem. > > Thanks. > > Jim > > > On 07/08/2012 17:46, Rick Curtis wrote: > >> Jim - >> >> No one else has reported memory leak issues when running with Audit >> support... but that doesn't mean there aren't problems. >> >> Can you post a heapdump to a FTP somewhere for analysis? >> >> Thanks, >> Rick >> >> On Mon, Aug 6, 2012 at 2:56 PM, Jim Talbut <jtal...@spudsoft.co.uk> >> wrote: >> >> Hi, >>> >>> I have an OSGi app that uses OpenJPA 2.2.0 and makes use of the audit >>> functionality. >>> Some of the entities that get recorded contain BLOB fields (documents). >>> >>> I'm getting occasional massive uses of memory (~900MB on a machine that >>> typically sits at ~150MB) closely followed by hangs and often a restart >>> by >>> the karaf wrapper. >>> >>> Looking at a memory dump I see that there are multiple copies of my BLOB >>> entity in memory (not just multiple records, but multiple copies of each >>> record) during a period of inactivity (where I wouldn't expect to see >>> any). >>> >>> Trying to track back responsibility for the objects gives me this tree: >>> this Document_JpaImpl >>> value ConcurrentHashMap$HashEntry >>> [0] ConcurrentHashMap$HashEntry[] >>> table ConcurrentHashMap$Segment >>> [7] ConcurrentHashMap$Segment[] >>> segments ConcurrentHashMap >>> _audits AuditManager$AuditCallback >>> [43] Object[] >>> elementData LifecycleEventManager$****ListenerList >>> ... >>> [43] Object[] >>> elementData LifecycleEventManager$****ListenerList >>> ... >>> [43] Object[] >>> elementData LifecycleEventManager$****ListenerList >>> >>> ... >>> this$0 >>> (I'm not sure how useful that is!) >>> >>> There are a lot of other duplicate JPA entities in memory too, but they >>> are smaller and less of a problem. >>> >>> Is this something I've done or a problem with OpenJPA? >>> >>> Thanks >>> >>> Jim >>> >>> >> >> > -- *Rick Curtis*
