openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Collins <Russell.Coll...@mclaneat.com>
Subject RE: FW: Memory leak
Date Thu, 23 Jul 2009 03:30:11 GMT
Correct.


Russell Collins
Sr. Software Engineer
McLane Advanced Technology

"Do or do not, there is no try." - Yoda

-----Original Message-----
From: Patrick Linskey [mailto:plinskey@gmail.com] 
Sent: Wednesday, July 22, 2009 9:43 PM
To: users@openjpa.apache.org
Subject: Re: FW: Memory leak

> I am using Geronimo to create my EntityManager.

Just to be clear, you're doing so by using an @PersistenceContext
annotation or looking up the EntityManager in JNDI, correct?

-Patrick

On Wed, Jul 22, 2009 at 6:47 PM, Russell
Collins<Russell.Collins@mclaneat.com> wrote:
> 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:plinskey@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.Collins@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:plinskey@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.Collins@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:daveminor@gmail.com]
>>> Sent: Wednesday, July 22, 2009 11:12 AM
>>> To: users@openjpa.apache.org; dev@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.dick@gmail.com]
>>>> Sent: Wednesday, July 22, 2009 6:47 AM
>>>> To: users@openjpa.apache.org; dev@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 dev@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 <daveminor@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 <daveminor@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.dick@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 <daveminor@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.dick@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
>>>> > > >> > <daveminor@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
>



-- 
Patrick Linskey
202 669 5907

Mime
View raw message