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




Reply via email to