Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Russell Collins <Russell.Collins@mclaneat.com>
To: "users@openjpa.apache.org" <users@openjpa.apache.org>,
	"dev@openjpa.apache.org" <dev@openjpa.apache.org>
Date: Wed, 22 Jul 2009 18:15:06 -0500
Subject: RE: FW: Memory leak
Thread-Topic: FW: Memory leak
Thread-Index: AcoK5zLGQImOrhuYQIOwmMtnE6xGEgAOt4Lw
Message-ID: 
 <69BEFCE5AAEBCA44B1301AD2360E83C79F7D5076E0@MATSVEC14.mclane.local>
References: 
 <4F457F4038D4E04BBC666DF701F4479C43D538@lilypad.teamestrogen.local>
 <be7371fa0907220911m585ad5a5h4057c8b21e4c255c@mail.gmail.com>
In-Reply-To: <be7371fa0907220911m585ad5a5h4057c8b21e4c255c@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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]=20
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
> >
>
>
>
>


--=20
_____________
David Minor