Return-Path: 
 <users-return-6416-apmail-openjpa-users-archive=openjpa.apache.org@openjpa.apache.org>
Delivered-To: apmail-openjpa-users-archive@minotaur.apache.org
Received: (qmail 1867 invoked from network); 14 Jan 2010 08:56:15 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 14 Jan 2010 08:56:15 -0000
Received: (qmail 51612 invoked by uid 500); 14 Jan 2010 08:56:14 -0000
Delivered-To: apmail-openjpa-users-archive@openjpa.apache.org
Received: (qmail 51550 invoked by uid 500); 14 Jan 2010 08:56:14 -0000
Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@openjpa.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@openjpa.apache.org>
List-Post: <mailto:users@openjpa.apache.org>
List-Id: <users.openjpa.apache.org>
Reply-To: users@openjpa.apache.org
Delivered-To: mailing list users@openjpa.apache.org
Received: (qmail 51540 invoked by uid 99); 14 Jan 2010 08:56:14 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Jan 2010 08:56:14 +0000
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [217.146.182.10] (HELO web27805.mail.ukl.yahoo.com)
 (217.146.182.10)
    by apache.org (qpsmtpd/0.29) with SMTP; Thu, 14 Jan 2010 08:56:03 +0000
Received: (qmail 78309 invoked by uid 60001); 14 Jan 2010 08:55:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024;
 t=1263459341; bh=6bb9w8LJpn8bloQHdez2oyJCnZz/VxG/2uurTDm8Exw=;
 h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
 b=zPyxfOiXSisJgYuW/O+l47+RydbZB0oyLK1IM6vYZko7f9ssJLX5p2VreZMQh3c7f12dAO+XqICfznDk/sbBN5XyrU8mQdpk0X/BZiEIxogjhIWNeyCDyug4MDxiqEcaZjfEmxby1MCmMz4vVEFSk6I5kQ+m+v3bEl8OS5vbyIk=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.de;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=En/pmUJWoMAasl5ZEEvK25claqbut8xFy99ORh9tpQFVMSqCcHVhYU5hriIOvd8gLPfi6sm07FNReyMSBhDJqUXF1hKCAgSLW/rqhFs24bROSLJK3BOusONR40ZLNMmSKcoIkw7Dbzkn7IPM3E6jnj4uxa7KRimSRmrEIP53tbk=;
Message-ID: <278076.78116.qm@web27805.mail.ukl.yahoo.com>
X-YMail-OSG: 
 pfbbxg4VM1k1.5KIdKj5Nq_1LzC4dAgUQ9vCeAR5F3BKeFJEe.UBmYdPvgTu42RgL77S0FcFpX4lsbJdea1RQycXpx8sID_FJwpTsfvUxJhANG3vjY_JsQL9HzyGHwUNU3HJO1QvvpRD4PjNlRTr370_Ta.Lr.cFQVPvg8g69OPePGVxUyto8beHkxZFCJ4eSIgabJsWu_YuXfm2uoVDvdcUf85MlMjI3LRyFZfiN8btreA8ZfyeSD6nVP80oow3DhBsHO9hMqUbPQENfs4aqjvl3vs_QVqYacuC6tTnsXy4KYB6cJCOIIRwQ21fvmLkUBw-
Received: from [80.108.118.219] by web27805.mail.ukl.yahoo.com via HTTP;
 Thu, 14 Jan 2010 08:55:41 GMT
X-Mailer: YahooMailClassic/9.0.20 YahooMailWebService/0.8.100.260964
Date: Thu, 14 Jan 2010 08:55:41 +0000 (GMT)
From: Mark Struberg <struberg@yahoo.de>
Subject: Re: memory leak? - simple question
To: users@openjpa.apache.org
In-Reply-To: <4B4E8F05.1090303@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Btw (slightly OT)=0A=0AYou could move addDefaultConstructor and enforceProp=
ertyRestrictions in your pom.xml to the configuration section of the openjp=
a-maven-plugin without, having to use the <toolProperties>. This should do =
exactly the same, but is easier to read ;)=0A=0A<configuration>=0A  <addDef=
aultConstructor>true</addDefaultConstructor>=0A  <enforcePropertyRestrictio=
ns>true</enforcePropertyRestrictions>=0A</configuration>=0A=0ALieGrue,=0Ast=
rub=0A=0A--- On Thu, 1/14/10, Kurt T Stam <kurt.stam@gmail.com> wrote:=0A=
=0A> From: Kurt T Stam <kurt.stam@gmail.com>=0A> Subject: Re: memory leak? =
- simple question=0A> To: users@openjpa.apache.org=0A> Date: Thursday, Janu=
ary 14, 2010, 4:27 AM=0A> Thanks Kevin,=0A> =0A> We're enhancing at build t=
ime:=0A> =0A> http://svn.apache.org/repos/asf/webservices/juddi/trunk/juddi=
-core/pom.xml=0A> =0A> Yeah we've been running load tests and things are ni=
ce and=0A> stable with =0A> Hibernate but with Openjpa we see increasing me=
mory use,=0A> blocking =0A> threads and then an OOM. http://issues.apache.o=
rg/jira/browse/JUDDI-267. =0A> Our preference would be to ship with openjpa=
 by default;=0A> but our build =0A> supports both hibernate and openjpa.=0A=
> =0A> And yes we use openjpa 1.2.1 (latest stable version).=0A> =0A> --Kur=
t=0A> =0A> Kevin Sutter wrote:=0A> > Interesting detective work, Kurt.=A0 T=
hanks.=0A> >=0A> > Why the WebService version of the app would behave=0A> d=
ifferently as far as GC=0A> > is concerned is a mystery.=A0 And, you said t=
hat=0A> plugging in Hibernate into=0A> > this scenario, everything works ok=
ay?=A0 Very=0A> confusing.=0A> >=0A> > How are you performing the Entity en=
hancement=0A> processing?=A0 Are you=0A> > pre-enhancing via your build pro=
cess?=A0 Or, are=0A> you using the -javaagent=0A> > mechanism?=A0 Or, are y=
ou falling back to the=0A> subclassing support within=0A> > OpenJPA?=A0 (Se=
e [1] for more information on these=0A> questions in case they=0A> > don't =
make sense.)=0A> >=0A> > This would be one area that is different between=
=0A> Hibernate and OpenJPA --=0A> > enhancement processing.=0A> >=0A> > In =
the Tomcat environment, you may be falling back to=0A> the subclassing=0A> =
> support (which we do not recommend) and hitting a=0A> memory leak with th=
at.=0A> >=0A> > You said OpenJPA 1.2.x, right?=0A> >=0A> > Just a couple of=
 thoughts on the subject...=0A> > Kevin=0A> >=0A> > [1]=0A> > http://websph=
erepersistence.blogspot.com/2009/02/openjpa-enhancement.html=0A> >=0A> >=0A=
> >=0A> > On Wed, Jan 13, 2010 at 4:25 PM, Kurt T Stam <kurt.stam@gmail.com=
>=0A> wrote:=0A> >=0A> >=A0=A0=A0=0A> >> The same code executed straight fr=
om a java client=0A> (inVM) shows no memory=0A> >> leak.=0A> >>=0A> >> So i=
s the fact that it is WebService significant=0A> then? What else can be=0A>=
 >> different? I think one thread remains up, and=0A> somehow this causes o=
penjpa=0A> >> not being able to clean up after itself. What can=0A> I do to=
 debug this more? I=0A> >> can actually see in the profiler that the object=
s=0A> are allocated by the=0A> >> WebService, but why aren't they cleaned u=
p?=0A> >>=0A> >> Thx,=0A> >>=0A> >>=0A> >> --Kurt=0A> >>=0A> >>=0A> >> Kurt=
 T Stam wrote:=0A> >>=0A> >>=A0 =A0=A0=A0=0A> >>> Thanks Kevin, thanks for =
your response.=0A> >>>=0A> >>> I just replaced the static call by:=0A> >>>=
=0A> >>>=A0 =A0 =A0 =A0 =A0 =A0=0A> =A0=A0=A0apiAuthToken =3D new=0A> org.u=
ddi.api_v3.AuthToken();=0A> >>>=A0 =A0 =A0 =A0 =A0 =A0=0A> =A0=A0=A0apiAuth=
Token.setAuthInfo(modelAuthToken.getAuthToken());=0A> >>>=A0 =A0 =A0 =A0 =
=A0 =A0=0A> =A0=A0=A0//MappingModelToApi.mapAuthToken(modelAuthToken,=0A> >=
>> apiAuthToken);=0A> >>>=0A> >>> which did not make a difference.=0A> >>>=
=0A> >>> I'm wondering if the fact that my class is a=0A> webservice makes =
a=0A> >>> difference. I'll try extracting it into=0A> >>> a regular class w=
ith a main method and profile=0A> that. At least I know that=0A> >>> I didn=
't forget something=0A> >>> completely obvious..=0A> >>>=0A> >>> --Kurt=0A>=
 >>>=0A> >>> Kevin Sutter wrote:=0A> >>>=0A> >>>=A0 =A0 =A0=A0=A0=0A> >>>> =
Kurt,=0A> >>>> I agree that this is very common usage of=0A> the JPA progra=
mming model.=0A> >>>>=A0 And,=0A> >>>> we are not aware of any memory=0A> l=
eaks.=A0 About the only thing that jumps=0A> >>>> out=0A> >>>> at me is the=
 following two lines:=0A> >>>>=0A> >>>>=A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 =
apiAuthToken =3D new=0A> org.uddi.api_v3.AuthToken();=0A> >>>>=A0 =A0 =A0 =
=A0 =A0 =A0=0A> =A0 =A0=0A> MappingModelToApi.mapAuthToken(modelAuthToken,=
=0A> >>>> apiAuthToken);=0A> >>>>=0A> >>>> What do these do?=A0 Can you com=
ment=0A> these out and see if the memory leak=0A> >>>> still exists?=A0 Sin=
ce you are passing=0A> the modelAuthToken into this method,=0A> >>>> I=0A> =
>>>> don't know what it's doing with the=0A> reference and could it be hold=
ing=0A> >>>> onto=0A> >>>> something to prevent the GC from cleaning=0A> up=
?=0A> >>>>=0A> >>>> The rest of your example seems very=0A> straight forwar=
d with creating and=0A> >>>> persisting objects.=0A> >>>>=0A> >>>> Kevin=0A=
> >>>>=0A> >>>> On Wed, Jan 13, 2010 at 2:09 PM, Rick=0A> Curtis <curtisr7@=
gmail.com>=0A> wrote:=0A> >>>>=0A> >>>>=0A> >>>>=0A> >>>>=A0 =A0 =A0 =A0=A0=
=A0=0A> >>>>> If you change the 1000 to something=0A> like 1000000... does =
your=0A> >>>>> application=0A> >>>>> go=0A> >>>>> OOM? Are you running in a=
 JSE=0A> environment? What is PersistenceManager?=0A> >>>>>=0A> >>>>> On We=
d, Jan 13, 2010 at 2:05 PM, Kurt=0A> T Stam <kurt.stam@gmail.com>=0A> >>>>>=
 wrote:=0A> >>>>>=0A> >>>>>=0A> >>>>>=0A> >>>>>=A0 =A0 =A0 =A0=0A> =A0=A0=
=A0=0A> >>>>>> BTW I'm running with the cache=0A> off=0A> >>>>>>=0A> >>>>>>=
 <property=0A> name=3D"openjpa.DataCache" value=3D"false"/>=0A> >>>>>>=0A> =
>>>>>> (that turns it off right?)=0A> >>>>>>=0A> >>>>>> --Kurt=0A> >>>>>>=
=0A> >>>>>>=0A> >>>>>>=0A> >>>>>> Kurt T Stam wrote:=0A> >>>>>>=0A> >>>>>>=
=0A> >>>>>>=0A> >>>>>>=A0 =A0 =A0 =A0 =A0=0A> =A0=A0=A0=0A> >>>>>>> Hi guys=
,=0A> >>>>>>>=0A> >>>>>>> [DESCRIPTION] The code below=0A> inserts a 1000 r=
ecords in the database.=0A> >>>>>>>=0A> >>>>>>> for (int i=3D1; i<1000; i++=
)=0A> {=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 EntityManager em =3D=0A> Persist=
enceManager.getEntityManager();=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 EntityTr=
ansaction tx =3D em.getTransaction();=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 tr=
y {=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 tx.begin();=0A> >>>>>>>=A0 =
=A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 // Generate auth token=0A> and store it=
!=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 String authInfo =3D AUTH_TOKEN=
_PREFIX +=0A> UUID.randomUUID();=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0=
 org.apache.juddi.model.AuthToken=0A> modelAuthToken =3D new=0A> >>>>>>>=0A=
> org.apache.juddi.model.AuthToken();=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =
=A0 =A0 if (authInfo !=3D null) {=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =
=A0 =A0 =A0=0A> modelAuthToken.setAuthToken(authInfo);=0A> >>>>>>>=A0 =A0 =
=A0 =A0=0A> =A0 =A0 =A0 =A0 =A0=0A> modelAuthToken.setCreated(new Date());=
=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0=0A> modelAuthToken.setL=
astUsed(new Date());=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0=0A>=
 modelAuthToken.setAuthorizedName(publisherId);=0A> >>>>>>>=A0 =A0 =A0 =A0=
=0A> =A0 =A0 =A0 =A0 =A0=0A> modelAuthToken.setNumberOfUses(0);=0A> >>>>>>>=
=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0=0A> modelAuthToken.setTokenState(AU=
THTOKEN_ACTIVE);=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0=0A>=
 em.persist(modelAuthToken);=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 }=
=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 apiAuthToken =3D new=0A> or=
g.uddi.api_v3.AuthToken();=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0=
=0A> MappingModelToApi.mapAuthToken(modelAuthToken,=0A> >>>>>>> apiAuthToke=
n);=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 tx.commit();=0A> >>>>>>>=
=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }=0A> finally {=0A> >>>=
>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 if (tx.isActive()) {=0A> >>>>>>>=A0 =A0=
 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 tx.rollback();=0A> >>>>>>>=A0 =A0 =A0 =A0=
=0A> =A0 =A0 =A0 }=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 em.clear();=
=0A> >>>>>>>=A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 em.close();=0A> >>>>>>>=A0 =A0 =
=A0 =A0=0A> =A0 }=0A> >>>>>>>=A0 =A0 =A0 }=0A> >>>>>>>=0A> >>>>>>>=0A> >>>>=
>>> [ISSUE]=0A> >>>>>>> After it leaving this code I=0A> end up with a 1000=
=0A> >>>>>>>=0A> org.apache.juddi.model.AuthToken objects in memory. I've=
=0A> been using=0A> >>>>>>> the=0A> >>>>>>> profiler, and these objects=0A>=
 cannot be garbage collected.=0A> >>>>>>>=0A> >>>>>>> This seems to be pret=
ty the=0A> most common use case of using an=0A> >>>>>>> OR-mapping=0A> >>>>=
>>> tool, so I find it hard to=0A> believe openjpa has a memory leak here.=
=0A> >>>>>>> Does=0A> >>>>>>> anyone see what I'm doing=0A> wrong? Or can s=
omeone point me to an example=0A> >>>>>>>=0A> >>>>>>>=0A> >>>>>>>=A0 =A0 =
=A0 =A0=0A> =A0 =A0 =A0=A0=A0=0A> >>>>>> that=0A> >>>>>>=A0 =A0 =A0 =A0 =A0=
=0A> =A0=A0=A0=0A> >>>>>=A0 =A0 =A0 =A0=0A> =A0=A0=A0=0A> >>>>>> does not e=
xhibit this behavior?=0A> BTW same code using hibernate does not=0A> >>>>>>=
=A0 =A0 =A0 =A0 =A0=0A> =A0=A0=A0=0A> >>>>>>> accumulate these objects.=0A>=
 >>>>>>>=0A> >>>>>>> We're using openjpa 1.2.1.=0A> >>>>>>>=0A> >>>>>>>=0A>=
 >>>>>>> Thx,=0A> >>>>>>>=0A> >>>>>>>=0A> >>>>>>> Kurt=0A> >>>>>>>=0A> >>>>=
>>> Apache jUDDI.=0A> >>>>>>>=0A> >>>>>>>=0A> >>>>>>>=0A> >>>>>>>=A0 =A0 =
=A0 =A0=0A> =A0 =A0 =A0=A0=A0=0A> >>>>>>=A0 =A0 =A0 =A0 =A0=0A> =A0=A0=A0=
=0A> >>>>> --=0A> >>>>> Thanks,=0A> >>>>> Rick=0A> >>>>>=0A> >>>>>=0A> >>>>=
>=0A> >>>>>=A0 =A0 =A0 =A0=0A> =A0=A0=A0=0A> >>>>=0A> >>>>=A0 =A0 =A0 =A0=
=A0=A0=0A> >>>=A0 =A0 =A0=A0=A0=0A> >=0A> >=A0=A0=A0=0A> =0A> =0A=0A=0A    =