openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Krzysztof <yaz...@gmail.com>
Subject Re: Memory leak for long-lived (read-only) EM?
Date Wed, 31 Oct 2012 01:34:50 GMT
Hello Rick,

Thanks for responding.
Yes, em.clear() is there after each transaction, memory grows and GC starts
to dominate at some point and finishes with OOM. Normally I'd expect few
tens of MBs to be occupied at each transaction.
A second thought: I use mvel (dynamically executed java on entities) here
and there's a chance it also keeps some references but did not spot it
anything related to it in during profiling or dump.

The link to heap dump is here:
http://www.isdc.unige.ch/Gaia/Download/heap.bin.gz
It was done after traversing ~100k entities, so 100k/200->500 transactions.
Not sure if it's relevant, but classA (SourceResult) is part of LRS.

The class hierarchy is sth like:
Catalog --LRS--> Source->TimeSeries
Run --LRS-> SourceResult->TimeSeriesResult
Run also references Catalog.

SourceId is (CatalogId,int)
TimeSeriesId is (SourceId,type)
SourceResultId is (Runid,SourceId)
TimeSeriesResultId is (SourceId,type)

where type is smallint.
SourceResult is derived from Source and references it back.

SourceResult is being traversed here in batches of 200, each in separate
transaction.

The persistent fields of entities are not modified, only some transient
ones.

Bucket holds all SourceResults Ids to be traversed (~400k)


 



--
View this message in context: http://openjpa.208410.n2.nabble.com/Memory-leak-for-long-lived-read-only-EM-tp7581554p7581564.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Mime
View raw message