Looks like this code was checked in a year ago by Patrick Linskey with the comment "Improve concurrency by actively managing AbstractBrokerFactory's broker set when using non-finalizing brokers. Credit goes to Arunabh Hazarika for identifying the bottleneck and prototyping this solution."
I'm not sure why _brokers was changed with regards to FinalizingBrokerImpl though. BrokerImpl's free() method was modified to call the factory to remove the it from _brokers. FinalizingBrokerImpl calls free() from its finalizer, but the finalizer will never be called if there is a reference in _brokers. Anyone have any ideas? On Tue, Jul 21, 2009 at 11:24 AM, David Minor <[email protected]> wrote: > 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 > > -- _____________ David Minor
