Re: Non-unique error
On Tue, Jan 12, 2010 at 10:43 PM, Pinaki Poddar ppod...@apache.org wrote: Everything works fine if I use fetch plan to load the collections (which I prefer) but I'm generally afraid of this due to bug [1]. [1] https://issues.apache.org/jira/browse/OPENJPA-1424 Use FetchPlan. OPENJPA-1424 is fixed. Yes, I recall you fixing it in the trunk. How can I get it in 1.2.1? -- Daryl Stultz _ 6 Degrees Software and Consulting, Inc. http://www.6degrees.com mailto:da...@6degrees.com
memory leak? - simple question
Hi guys, [DESCRIPTION] The code below inserts a 1000 records in the database. for (int i=1; i1000; 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.
Re: memory leak? - simple question
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; i1000; 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.
Re: memory leak? - simple question
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 curti...@gmail.com wrote: If you change the 1000 to something like 100... 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.s...@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; i1000; 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
Re: memory leak? - simple question
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 curti...@gmail.com wrote: If you change the 1000 to something like 100... 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.s...@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; i1000; 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
Re: memory leak? - simple question
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.s...@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 curti...@gmail.com wrote: If you change the 1000 to something like 100... 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.s...@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; i1000; 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
Re: memory leak? - simple question
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.s...@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 curti...@gmail.com wrote: If you change the 1000 to something like 100... 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.s...@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; i1000; 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()) {