You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Mauro Flores <ma...@procergs.rs.gov.br> on 2009/05/26 00:13:35 UTC
Memory Leak and JJCalls
Hi,
I'm getting memory leak in my aplication server. When I use a tool to see
which object has more instances in memory, I find this class in the top
five: org.apache.openjpa.kernel.jpql.JPQL$JJCalls.
>From this information, is it possible to imply that I not working correctly
with JPA api, and this could be the reason of mem leak?
My EntityManagers are managed by EJB. I don't opened neither close it.
Thanks for some hint,
Mauro.
--
View this message in context: http://n2.nabble.com/Memory-Leak-and-JJCalls-tp2971921p2971921.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Memory Leak and JJCalls
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Mauro,
The Query Compilation Cache is ON by default. You don't have to do anything
with this. I was just pointing out the functionality.
Since you are using the OpenJPA 1.1.x branch, I'm going to copy the owner of
that branch on the chance that there's something already known in this
area. Like I mentioned in the previous reply, maybe there's something in
the app server (WebLogic in this case) that is not cleaning up the
EntityManagers appropriately.
It sounds and looks like you have a fairly straight-forward configuration,
so hopefully we'll get a reply from someone more familiar with the 1.1.x
branch.
Kevin
On Tue, May 26, 2009 at 4:44 PM, Mauro Flores <
mauro-flores@procergs.rs.gov.br> wrote:
>
> I'm not using so far any custom openjpa property like 'Query Compilation
> Cache'. I'll try to use some of them.
>
> My scenario is this:
>
> application server: weblogic 10.3
> version kodo: 1.0.0.0_4-2-0
> version openjpa: 1.1.0
>
> Persistence XML
>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
> version="1.0">
> <persistence-unit name="CAF">
>
> <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
> <jta-data-source>CafDS</jta-data-source>
> <mapping-file>META-INF/orm.xml</mapping-file>
> <class>...</class>
> </persistence-unit>
> </persistence>
>
> Thanks!
> --
> View this message in context:
> http://n2.nabble.com/Memory-Leak-and-JJCalls-tp2971921p2977452.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
Re: Memory Leak and JJCalls
Posted by Mauro Flores <ma...@procergs.rs.gov.br>.
I'm not using so far any custom openjpa property like 'Query Compilation
Cache'. I'll try to use some of them.
My scenario is this:
application server: weblogic 10.3
version kodo: 1.0.0.0_4-2-0
version openjpa: 1.1.0
Persistence XML
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
version="1.0">
<persistence-unit name="CAF">
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
<jta-data-source>CafDS</jta-data-source>
<mapping-file>META-INF/orm.xml</mapping-file>
<class>...</class>
</persistence-unit>
</persistence>
Thanks!
--
View this message in context: http://n2.nabble.com/Memory-Leak-and-JJCalls-tp2971921p2977452.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Memory Leak and JJCalls
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Mauro,
Hmmm... There can be a lots of reasons for memory leaks. I am not aware of
any memory leaks in the OpenJPA code at this time, but that doesn't mean
that some are not still waiting to be discovered...
First off, the jpql package that you reference is used for parsing the JPQL
that is being used by your application. I'd very surpised if this package
was the culprit of the memory leak. More than likely, this is due to some
references that are not being cleaned up properly. Normally, memory
analysis tools will allow you to go "up the stack" and see where the
references are coming from. Any other hints in this area?
OpenJPA provides a Query Compilation Cache that is on by default. This
cache is for caching the parsed aspects of JPQL so that we don't have to
parse the same strings over and over again. But, if this cache was getting
too large, you would see a different Class referenced in your memory
analysis.
What version of OpenJPA are you using? There have been various improvements
through out the lifetime of OpenJPA related to memory usage, locking,
threading, etc that may come into play with your scenario.
You mention that you are using Container-managed persistence. Which
application server are you using? A common problem with Application-managed
persistence is not cleaning up the EntityManagers properly (thus causing
memory leaks). I suppose it's possible that the Container-managed
persistence you are using has a problem with your scenario.
Let's start the conversation and see where it takes us.
Kevin
On Mon, May 25, 2009 at 5:13 PM, Mauro Flores <
mauro-flores@procergs.rs.gov.br> wrote:
>
> Hi,
>
> I'm getting memory leak in my aplication server. When I use a tool to see
> which object has more instances in memory, I find this class in the top
> five: org.apache.openjpa.kernel.jpql.JPQL$JJCalls.
>
> From this information, is it possible to imply that I not working correctly
> with JPA api, and this could be the reason of mem leak?
>
> My EntityManagers are managed by EJB. I don't opened neither close it.
>
> Thanks for some hint,
>
> Mauro.
> --
> View this message in context:
> http://n2.nabble.com/Memory-Leak-and-JJCalls-tp2971921p2971921.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>