openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Talbut <jtal...@spudsoft.co.uk>
Subject Re: Audit(?) related memory leak/hog
Date Mon, 20 Aug 2012 16:24:09 GMT
Thanks Rick.
I've failed a Jira for this as https://issues.apache.org/jira/browse/OPENJPA-2253

Jim

On Wed, Aug 08, 2012 at 04:18:33PM -0500, Rick Curtis wrote:
> 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 <jtalbut@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 <jtalbut@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*

Mime
View raw message