I am using Geronimo to create my EntityManager.
Russell Collins Sr. Software Engineer McLane Advanced Technology "Do or do not, there is no try." - Yoda -----Original Message----- From: Patrick Linskey [mailto:plins...@gmail.com] Sent: Wednesday, July 22, 2009 7:49 PM To: users@openjpa.apache.org Subject: Re: FW: Memory leak Hi, How are you getting the EM? IIRC (and no, I'm not looking at the code right now -- I could be very wrong), OpenJPA uses the non-finalizing approach automatically when PersistenceProvider.createContainerEntityManagerFactory() is used. If your EM / EMF is injected by Geronimo, then Geronimo should be creating the EMF via this method, so it should automatically be working. However, if you're manually creating an EMF using Persistence.createEntityManagerFactory(), Geronimo's lifecycle management is bypassed. -Patrick On Wed, Jul 22, 2009 at 5:26 PM, Russell Collins<russell.coll...@mclaneat.com> wrote: > I am using the openjpa within the Geronimo container. Is there a way that I > can tell Geronimo to do this or is this a question for the Geronimo group? > > > Russell Collins > Sr. Software Engineer > McLane Advanced Technology > > "Do or do not, there is no try." - Yoda > > > -----Original Message----- > From: Patrick Linskey [mailto:plins...@gmail.com] > Sent: Wednesday, July 22, 2009 6:58 PM > To: users@openjpa.apache.org > Subject: Re: FW: Memory leak > > Hi, > > Is there any particular reason why you need the finalizing broker? One > (vastly preferable) option would be to use the non-finalizing broker, > which, of course, means that you're promising to close your brokers at > the appropriate lifecycle moments. > > Certainly, the bug deserves to be addressed, as the whole point of the > finalizing mode is to be robust in an environment with dubious cleanup > practices. > > -Patrick > > On Wed, Jul 22, 2009 at 4:15 PM, Russell > Collins<russell.coll...@mclaneat.com> wrote: >> Is there a configuration setting or work around for this in the meantime? >> >> >> Russell Collins >> Sr. Software Engineer >> McLane Advanced Technology >> >> "Do or do not, there is no try." - Yoda >> >> >> -----Original Message----- >> From: David Minor [mailto:davemi...@gmail.com] >> Sent: Wednesday, July 22, 2009 11:12 AM >> To: users@openjpa.apache.org; d...@openjpa.apache.org >> Subject: Re: FW: Memory leak >> >> I've created http://issues.apache.org/jira/browse/OPENJPA-1193 >> >> One thought I had was that the if statement might simply be missing a ! -- >> since this is a concurrency improvement for non-finalizing brokers, perhaps >> the non-finalizing brokers were supposed to be switched to the >> ConcurrentHashMap, rather than the finalizing brokers. >> >> Is Patrick Linskey still involved in openjpa? I haven't seen his name for >> awhile. >> >> >>> -----Original Message----- >>> From: Michael Dick [mailto:michael.d.d...@gmail.com] >>> Sent: Wednesday, July 22, 2009 6:47 AM >>> To: users@openjpa.apache.org; d...@openjpa.apache.org >>> Subject: Re: FW: Memory leak >>> >>> Hi David, >>> >>> At the moment I don't have a ton of free time to dive into the change or >>> the peformance bottleneck that it resolved. In the interest of providing >>> some relief (trunk & 1.3.x) I'd be happy to make this change >>> configurable (maybe something on openjpa.conf.Compatibility) so you can >>> get the old behavior. >>> >>> I've cross posted to d...@openjpa to see if there are any objections. >>> >>> In any event would you mind opening a JIRA issue (I'd do it but then you >>> have to subscribe to get notifications etc.). >>> >>> On Tue, Jul 21, 2009 at 6:37 PM, David Minor <davemi...@gmail.com> >>> wrote: >>> >>> > 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 <davemi...@gmail.com> >>> 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:michael.d.d...@gmail.com] >>> > > > Sent: Tuesday, July 14, 2009 7:29 AM >>> > > > To: users@openjpa.apache.org >>> > > > 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 <davemi...@gmail.com> >>> > > > 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:michael.d.d...@gmail.com] >>> > > >> > Sent: Monday, July 13, 2009 12:49 PM >>> > > >> > To: users@openjpa.apache.org >>> > > >> > 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 >>> > > >> > <davemi...@gmail.com> >>> > > >> > 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 >>> > >>> >>> >>> >>> >> >> >> -- >> _____________ >> David Minor >> > > > > -- > Patrick Linskey > 202 669 5907 > -- Patrick Linskey 202 669 5907
