Hi Mike,
I've tracked the problem down to
org.apache.openjpa.kernel.AbstractBrokerFactory. The heap dump lists the
_brokers Set as containing all the references to FinalizingBrokerImpl, and
it appears the assignment of this set was changed to this:
if (FinalizingBrokerImpl.class.isAssignableFrom(
bv.getTemplateBrokerType(_conf))) {
return MapBackedSet.decorate(new ConcurrentHashMap(),
new Object() { });
} else {
return new ConcurrentReferenceHashSet(
ConcurrentReferenceHashSet.WEAK);
}
It used to be assigned to the weak reference hash set as in the else
statement. Forcing the second assignment fixes the problem.
>
> -----Original Message-----
> From: Michael Dick [mailto:[email protected]]
> Sent: Tuesday, July 14, 2009 7:29 AM
> To: [email protected]
> Subject: Re: FW: Memory leak
>
> Hi David,
>
> There have been a few changes in PersistenceProviderImpl. One was to
> make the non-finalizing BrokerImpl the default (must be overridden in
> your
> config) another that might be interesting was adding a pool of
> EntityManagerFactories.
>
> From what I've seen the EMF pool is not used by default, but it's
> possible that the AbstractEntityManagerFactoryBean is setting it (the
> property is named EntityManagerFactoryPool in case that helps). I took
> a quick pass at setting the pooling property and the only way I saw it
> take effect was to pass it in as a JVM arg (might be something in my
> eclipse env though - and I'm on 2.0.0-SNAPSHOT ATM).
>
> Hope this gives you a starting point, if not keep replying and we'll try
> to help
>
> -mike
>
> On Mon, Jul 13, 2009 at 8:00 PM, David Minor <[email protected]>
> wrote:
>
>> Hi Mike,
>>
>> Nothing else has changed. The application extends spring 2.0's
>> AbstractEntityManagerFactoryBean class (apparently so that the
>> persistence.xml file can be named something different).
>>
>> I notice it is checking the return type of
>> AbstractEntityManagerFactoryBean's getPersistenceProvider() for an
>> instance of openjpa's PersistenceProviderImpl, and doing something
>> different depending on whether it finds it or not. Has anything
>> changed with regards to this class?
>>
>> > -----Original Message-----
>> > From: Michael Dick [mailto:[email protected]]
>> > Sent: Monday, July 13, 2009 12:49 PM
>> > To: [email protected]
>> > Subject: Re: Memory leak
>> >
>> > Hi David,
>> >
>> > FinalizingBrokerImpl will close itself and free resources when it's
>> > GC'ed.
>> > It sounds like something else is holding on to a lot of references
>> > to FBImpl (I'd guess something changed "upstream").
>> >
>> > One cause is if the application creates a large number of
>> > EntityManagers and doesn't close them (or creates a large number of
>> > EMFactories which don't get closed since closing an EMF will close
> its EMs).
>> >
>> > Did anything else change or did you just upgrade OpenJPA versions?
>> >
>> > -mike
>> >
>> > On Mon, Jul 13, 2009 at 11:34 AM, David Minor <[email protected]>
>> > wrote:
>> >
>> >> Upgrading openjpa from 1.0.1 to 1.2.1 seems to introduce a memory
>> >> leak
>> >
>> >> in our application -- leaving the server running for a few days
>> >> results in OOM errors (there are quartz tasks making simple openjpa
>
>> >> selects during this time). A heap dump reveals
>> >> org.apache.openjpa.kernel.FinalizingBrokerImpl as the dominant
>> >> object,
>> >
>> >> according to Eclipse's memory analysis plugin.
>> >>
>> >> Does anyone have an idea of what might be causing this?
>> >>
>> >> --
>> >> _____________
>> >> David Minor
>> >>
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> _____________
>> David Minor
>>
>
>
>
>
--
_____________
David Minor
