openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: memory leak? - simple question
Date Thu, 14 Jan 2010 08:55:41 GMT
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 <kurt.stam@gmail.com> wrote:

> From: Kurt T Stam <kurt.stam@gmail.com>
> Subject: Re: memory leak? - simple question
> To: users@openjpa.apache.org
> 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 <kurt.stam@gmail.com>
> 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 <curtisr7@gmail.com>
> 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 <kurt.stam@gmail.com>
> >>>>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>       
>    
> >>>>
> >>>>         
> >>>       
> >
> >   
> 
> 


      

Mime
View raw message