Btw (slightly OT) You could move addDefaultConstructor and enforcePropertyRestrictions in your pom.xml to the configuration section of the openjpa-maven-plugin without, having to use the <toolProperties>. This should do exactly the same, but is easier to read ;)
<configuration> <addDefaultConstructor>true</addDefaultConstructor> <enforcePropertyRestrictions>true</enforcePropertyRestrictions> </configuration> LieGrue, strub --- On Thu, 1/14/10, Kurt T Stam <[email protected]> wrote: > From: Kurt T Stam <[email protected]> > Subject: Re: memory leak? - simple question > To: [email protected] > Date: Thursday, January 14, 2010, 4:27 AM > Thanks Kevin, > > We're enhancing at build time: > > http://svn.apache.org/repos/asf/webservices/juddi/trunk/juddi-core/pom.xml > > Yeah we've been running load tests and things are nice and > stable with > Hibernate but with Openjpa we see increasing memory use, > blocking > threads and then an OOM. http://issues.apache.org/jira/browse/JUDDI-267. > Our preference would be to ship with openjpa by default; > but our build > supports both hibernate and openjpa. > > And yes we use openjpa 1.2.1 (latest stable version). > > --Kurt > > Kevin Sutter wrote: > > Interesting detective work, Kurt. Thanks. > > > > Why the WebService version of the app would behave > differently as far as GC > > is concerned is a mystery. And, you said that > plugging in Hibernate into > > this scenario, everything works okay? Very > confusing. > > > > How are you performing the Entity enhancement > processing? Are you > > pre-enhancing via your build process? Or, are > you using the -javaagent > > mechanism? Or, are you falling back to the > subclassing support within > > OpenJPA? (See [1] for more information on these > questions in case they > > don't make sense.) > > > > This would be one area that is different between > Hibernate and OpenJPA -- > > enhancement processing. > > > > In the Tomcat environment, you may be falling back to > the subclassing > > support (which we do not recommend) and hitting a > memory leak with that. > > > > You said OpenJPA 1.2.x, right? > > > > Just a couple of thoughts on the subject... > > Kevin > > > > [1] > > http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html > > > > > > > > On Wed, Jan 13, 2010 at 4:25 PM, Kurt T Stam <[email protected]> > wrote: > > > > > >> The same code executed straight from a java client > (inVM) shows no memory > >> leak. > >> > >> So is the fact that it is WebService significant > then? What else can be > >> different? I think one thread remains up, and > somehow this causes openjpa > >> not being able to clean up after itself. What can > I do to debug this more? I > >> can actually see in the profiler that the objects > are allocated by the > >> WebService, but why aren't they cleaned up? > >> > >> Thx, > >> > >> > >> --Kurt > >> > >> > >> Kurt T Stam wrote: > >> > >> > >>> Thanks Kevin, thanks for your response. > >>> > >>> I just replaced the static call by: > >>> > >>> > apiAuthToken = new > org.uddi.api_v3.AuthToken(); > >>> > apiAuthToken.setAuthInfo(modelAuthToken.getAuthToken()); > >>> > //MappingModelToApi.mapAuthToken(modelAuthToken, > >>> apiAuthToken); > >>> > >>> which did not make a difference. > >>> > >>> I'm wondering if the fact that my class is a > webservice makes a > >>> difference. I'll try extracting it into > >>> a regular class with a main method and profile > that. At least I know that > >>> I didn't forget something > >>> completely obvious.. > >>> > >>> --Kurt > >>> > >>> Kevin Sutter wrote: > >>> > >>> > >>>> Kurt, > >>>> I agree that this is very common usage of > the JPA programming model. > >>>> And, > >>>> we are not aware of any memory > leaks. About the only thing that jumps > >>>> out > >>>> at me is the following two lines: > >>>> > >>>> > apiAuthToken = new > org.uddi.api_v3.AuthToken(); > >>>> > > MappingModelToApi.mapAuthToken(modelAuthToken, > >>>> apiAuthToken); > >>>> > >>>> What do these do? Can you comment > these out and see if the memory leak > >>>> still exists? Since you are passing > the modelAuthToken into this method, > >>>> I > >>>> don't know what it's doing with the > reference and could it be holding > >>>> onto > >>>> something to prevent the GC from cleaning > up? > >>>> > >>>> The rest of your example seems very > straight forward with creating and > >>>> persisting objects. > >>>> > >>>> Kevin > >>>> > >>>> On Wed, Jan 13, 2010 at 2:09 PM, Rick > Curtis <[email protected]> > wrote: > >>>> > >>>> > >>>> > >>>> > >>>>> If you change the 1000 to something > like 1000000... does your > >>>>> application > >>>>> go > >>>>> OOM? Are you running in a JSE > environment? What is PersistenceManager? > >>>>> > >>>>> On Wed, Jan 13, 2010 at 2:05 PM, Kurt > T Stam <[email protected]> > >>>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>> > > >>>>>> BTW I'm running with the cache > off > >>>>>> > >>>>>> <property > name="openjpa.DataCache" value="false"/> > >>>>>> > >>>>>> (that turns it off right?) > >>>>>> > >>>>>> --Kurt > >>>>>> > >>>>>> > >>>>>> > >>>>>> Kurt T Stam wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > > >>>>>>> Hi guys, > >>>>>>> > >>>>>>> [DESCRIPTION] The code below > inserts a 1000 records in the database. > >>>>>>> > >>>>>>> for (int i=1; i<1000; i++) > { > >>>>>>> > EntityManager em = > PersistenceManager.getEntityManager(); > >>>>>>> > EntityTransaction tx = em.getTransaction(); > >>>>>>> > try { > >>>>>>> > tx.begin(); > >>>>>>> > // Generate auth token > and store it! > >>>>>>> > String authInfo = AUTH_TOKEN_PREFIX + > UUID.randomUUID(); > >>>>>>> > org.apache.juddi.model.AuthToken > modelAuthToken = new > >>>>>>> > org.apache.juddi.model.AuthToken(); > >>>>>>> > if (authInfo != null) { > >>>>>>> > > modelAuthToken.setAuthToken(authInfo); > >>>>>>> > > modelAuthToken.setCreated(new Date()); > >>>>>>> > > modelAuthToken.setLastUsed(new Date()); > >>>>>>> > > modelAuthToken.setAuthorizedName(publisherId); > >>>>>>> > > modelAuthToken.setNumberOfUses(0); > >>>>>>> > > modelAuthToken.setTokenState(AUTHTOKEN_ACTIVE); > >>>>>>> > > em.persist(modelAuthToken); > >>>>>>> > } > >>>>>>> > apiAuthToken = new > org.uddi.api_v3.AuthToken(); > >>>>>>> > > MappingModelToApi.mapAuthToken(modelAuthToken, > >>>>>>> apiAuthToken); > >>>>>>> > tx.commit(); > >>>>>>> > } > finally { > >>>>>>> > if (tx.isActive()) { > >>>>>>> > tx.rollback(); > >>>>>>> > } > >>>>>>> > em.clear(); > >>>>>>> > em.close(); > >>>>>>> > } > >>>>>>> } > >>>>>>> > >>>>>>> > >>>>>>> [ISSUE] > >>>>>>> After it leaving this code I > end up with a 1000 > >>>>>>> > org.apache.juddi.model.AuthToken objects in memory. I've > been using > >>>>>>> the > >>>>>>> profiler, and these objects > cannot be garbage collected. > >>>>>>> > >>>>>>> This seems to be pretty the > most common use case of using an > >>>>>>> OR-mapping > >>>>>>> tool, so I find it hard to > believe openjpa has a memory leak here. > >>>>>>> Does > >>>>>>> anyone see what I'm doing > wrong? Or can someone point me to an example > >>>>>>> > >>>>>>> > >>>>>>> > > >>>>>> that > >>>>>> > > >>>>> > > >>>>>> does not exhibit this behavior? > BTW same code using hibernate does not > >>>>>> > > >>>>>>> accumulate these objects. > >>>>>>> > >>>>>>> We're using openjpa 1.2.1. > >>>>>>> > >>>>>>> > >>>>>>> Thx, > >>>>>>> > >>>>>>> > >>>>>>> Kurt > >>>>>>> > >>>>>>> Apache jUDDI. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > > >>>>>> > > >>>>> -- > >>>>> Thanks, > >>>>> Rick > >>>>> > >>>>> > >>>>> > >>>>> > > >>>> > >>>> > >>> > > > > > >
