JDBC connection pool memory leak

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

JDBC connection pool memory leak

Bjorn Danielsson
Hi people,

I get memory leaks from the built-in TomEE JDBC connection pool,
using the default container-managed persistence and transactions.

I have some code in a Singleton EJB that does, essentially, this:

    @PersistenceUnit(unitName = "MyApp")
    EntityManagerFactory emf;

    @Schedule(second="*/10", minute="*", hour="*")
    public void tickTock() {
        EntityManager em = emf.createEntityManager();
        em.find(MyTrivialEntity.class, 1);
    }

Every time tickTock() is invoked, jmap -histo:live reports objects
being added permanently to the heap:

 num     #instances         #bytes  class name
----------------------------------------------
[...]
 270:             6           1584  com.mysql.jdbc.JDBC4PreparedStatement
 322:             6           1056  com.mysql.jdbc.JDBC4ResultSet

These #instances and #bytes values increase at a steady pace,
and if I leave it running long enough this causes OutOfMemory.
The number of connections doesn't grow: both mysqladmin and jmap
consistently report 3 simultaneous connections all the time.

It doesn't matter if I use Eclipselink instead of OpenJPA.

But the memory leak goes away if I change the database from Mysql
to embedded Derby, so I assume there is some quirkiness in the
Mysql driver that is involved.

The memory leak also goes away if I revert to using commons-dbcp
for the pool.

MaxAge <N> is a workaround, but how do I choose <N> for any
specific load? This is not an attractive solution.

I searched a lot before I posted this, and I found recommendations
that you should always close SQL Statements and ResultSets before
returning connections to the pool. But I have to trust the container
to do this when I am using JPA, right? Or am I missing something?

Version info:

apache-tomee-1.5.1-plus (I also tried today's 1.5.2 snapshot)
mysql-connector-java-5.1.22
jdk-7u9

--
Bjorn Danielsson
Cuspy Code AB
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

smithh032772
Very interesting info here, thanks for sharing.

I have been using TomEE since 1.5.1-SNAPSHOT and now 1.5.2-SNAPSHOT. Also,
I'm using Apache Derby 10.9.1.0 and Eclipse 2.3.2, and JDBC configured in
tomee.xml.

Can you share your JDBC config from your tomee.xml and/or context.xml?

Apache Derby is working fine for me, but I think I'm experiencing memory
leaks that are possibly caused by Google Calendar API's use of
threadlocal/etc... No need to discuss that here in this thread.


On Thu, Jan 3, 2013 at 1:54 PM, Bjorn Danielsson <
[hidden email]> wrote:

> It doesn't matter if I use Eclipselink instead of OpenJPA.
>
> But the memory leak goes away if I change the database from Mysql
> to embedded Derby, so I assume there is some quirkiness in the
> Mysql driver that is involved.
>
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Romain Manni-Bucau
Hi,

did you try to reproduce it with tomcat-jdbc (in a simple test without
tomee or any other framework)?

i wonder if it is linked to tomee or tomcat-jdbc directly (or mysql
since derby seems fine)

any more info or even a test reproducing the issue (in a reasonnable
time) would be great.

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2013/1/3 Howard W. Smith, Jr. <[hidden email]>:

> Very interesting info here, thanks for sharing.
>
> I have been using TomEE since 1.5.1-SNAPSHOT and now 1.5.2-SNAPSHOT. Also,
> I'm using Apache Derby 10.9.1.0 and Eclipse 2.3.2, and JDBC configured in
> tomee.xml.
>
> Can you share your JDBC config from your tomee.xml and/or context.xml?
>
> Apache Derby is working fine for me, but I think I'm experiencing memory
> leaks that are possibly caused by Google Calendar API's use of
> threadlocal/etc... No need to discuss that here in this thread.
>
>
> On Thu, Jan 3, 2013 at 1:54 PM, Bjorn Danielsson <
> [hidden email]> wrote:
>
>> It doesn't matter if I use Eclipselink instead of OpenJPA.
>>
>> But the memory leak goes away if I change the database from Mysql
>> to embedded Derby, so I assume there is some quirkiness in the
>> Mysql driver that is involved.
>>
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Anthony Fryer
In reply to this post by Bjorn Danielsson
What happens if you call the close() method on the EntityManager at the end of your method?
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Romain Manni-Bucau
It will do pretty much nothing in cmp beans.

Btw found http://jira.jasmine.objectweb.org/browse/MONITORING-266
Le 3 janv. 2013 23:45, "Anthony Fryer" <[hidden email]> a écrit :

> What happens if you call the close() method on the EntityManager at the end
> of your method?
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/JDBC-connection-pool-memory-leak-tp4660054p4660059.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Bjorn Danielsson
In reply to this post by Romain Manni-Bucau
I just reproduced the memory leak in a plain Tomcat 7.0.34,
using only JDBC and a Mysql datasource:

    InitialContext ctx = new InitialContext();
    DataSource ds = (DataSource) ctx.lookup("java:/comp/env/jdbc/test");
    Connection conn = ds.getConnection();
    PreparedStatement stmt = conn.prepareStatement("SELECT * FROM MYTABLE");
    ResultSet rs = stmt.executeQuery();
    conn.close();

I put the above code in a JSP file, then after each request I
did "jmap -histo:live 4711 | grep com.mysql.jdbc.JDBC4".
The numbers increment steadily.

Adding stmt.close() before conn.close() makes the leak go away.

Using jdbcInterceptors="StatementFinalizer" in the pool helps.
This seems to be the documented way to deal with this. However
when I tried "StatementFinalizer" in TomEE it had no effect.
The attribute was recognized, because if I misspelled the value
I got an error message in TomEE's catalina.out.

With Tomcat and commons-dbcp (the default) it was impossible
to reproduce the memory leak even when I neglected to close
the Connection proxy.

I can provide an isolated TomEE example that reproduces the
problem, but I need to disentangle it from my main project
code first.

--
Bjorn Danielsson
Cuspy Code AB


Romain Manni-Bucau <[hidden email]> wrote:

> Hi,
>
> did you try to reproduce it with tomcat-jdbc (in a simple test without
> tomee or any other framework)?
>
> i wonder if it is linked to tomee or tomcat-jdbc directly (or mysql
> since derby seems fine)
>
> any more info or even a test reproducing the issue (in a reasonnable
> time) would be great.
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/1/3 Howard W. Smith, Jr. <[hidden email]>:
>> Very interesting info here, thanks for sharing.
>>
>> I have been using TomEE since 1.5.1-SNAPSHOT and now 1.5.2-SNAPSHOT. Also,
>> I'm using Apache Derby 10.9.1.0 and Eclipse 2.3.2, and JDBC configured in
>> tomee.xml.
>>
>> Can you share your JDBC config from your tomee.xml and/or context.xml?
>>
>> Apache Derby is working fine for me, but I think I'm experiencing memory
>> leaks that are possibly caused by Google Calendar API's use of
>> threadlocal/etc... No need to discuss that here in this thread.
>>
>>
>> On Thu, Jan 3, 2013 at 1:54 PM, Bjorn Danielsson <
>> [hidden email]> wrote:
>>
>>> It doesn't matter if I use Eclipselink instead of OpenJPA.
>>>
>>> But the memory leak goes away if I change the database from Mysql
>>> to embedded Derby, so I assume there is some quirkiness in the
>>> Mysql driver that is involved.
>>>
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Romain Manni-Bucau
Hi,

great progress!

just to be sure to understand:

in a plain tomcat does StatementFinalizer replace stmt.close() to make
the leak going away?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2013/1/4 Bjorn Danielsson <[hidden email]>:

> I just reproduced the memory leak in a plain Tomcat 7.0.34,
> using only JDBC and a Mysql datasource:
>
>     InitialContext ctx = new InitialContext();
>     DataSource ds = (DataSource) ctx.lookup("java:/comp/env/jdbc/test");
>     Connection conn = ds.getConnection();
>     PreparedStatement stmt = conn.prepareStatement("SELECT * FROM MYTABLE");
>     ResultSet rs = stmt.executeQuery();
>     conn.close();
>
> I put the above code in a JSP file, then after each request I
> did "jmap -histo:live 4711 | grep com.mysql.jdbc.JDBC4".
> The numbers increment steadily.
>
> Adding stmt.close() before conn.close() makes the leak go away.
>
> Using jdbcInterceptors="StatementFinalizer" in the pool helps.
> This seems to be the documented way to deal with this. However
> when I tried "StatementFinalizer" in TomEE it had no effect.
> The attribute was recognized, because if I misspelled the value
> I got an error message in TomEE's catalina.out.
>
> With Tomcat and commons-dbcp (the default) it was impossible
> to reproduce the memory leak even when I neglected to close
> the Connection proxy.
>
> I can provide an isolated TomEE example that reproduces the
> problem, but I need to disentangle it from my main project
> code first.
>
> --
> Bjorn Danielsson
> Cuspy Code AB
>
>
> Romain Manni-Bucau <[hidden email]> wrote:
>> Hi,
>>
>> did you try to reproduce it with tomcat-jdbc (in a simple test without
>> tomee or any other framework)?
>>
>> i wonder if it is linked to tomee or tomcat-jdbc directly (or mysql
>> since derby seems fine)
>>
>> any more info or even a test reproducing the issue (in a reasonnable
>> time) would be great.
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2013/1/3 Howard W. Smith, Jr. <[hidden email]>:
>>> Very interesting info here, thanks for sharing.
>>>
>>> I have been using TomEE since 1.5.1-SNAPSHOT and now 1.5.2-SNAPSHOT. Also,
>>> I'm using Apache Derby 10.9.1.0 and Eclipse 2.3.2, and JDBC configured in
>>> tomee.xml.
>>>
>>> Can you share your JDBC config from your tomee.xml and/or context.xml?
>>>
>>> Apache Derby is working fine for me, but I think I'm experiencing memory
>>> leaks that are possibly caused by Google Calendar API's use of
>>> threadlocal/etc... No need to discuss that here in this thread.
>>>
>>>
>>> On Thu, Jan 3, 2013 at 1:54 PM, Bjorn Danielsson <
>>> [hidden email]> wrote:
>>>
>>>> It doesn't matter if I use Eclipselink instead of OpenJPA.
>>>>
>>>> But the memory leak goes away if I change the database from Mysql
>>>> to embedded Derby, so I assume there is some quirkiness in the
>>>> Mysql driver that is involved.
>>>>
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Bjorn Danielsson
Romain Manni-Bucau <[hidden email]> wrote:
>
> just to be sure to understand:
>
> in a plain tomcat does StatementFinalizer replace stmt.close() to make
> the leak going away?

Yes.

--
Bjorn Danielsson
Cuspy Code AB
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Romain Manni-Bucau
ok so can you share a sample reproducing the issue please?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2013/1/4 Bjorn Danielsson <[hidden email]>:

> Romain Manni-Bucau <[hidden email]> wrote:
>>
>> just to be sure to understand:
>>
>> in a plain tomcat does StatementFinalizer replace stmt.close() to make
>> the leak going away?
>
> Yes.
>
> --
> Bjorn Danielsson
> Cuspy Code AB
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Bjorn Danielsson
Hi Romain,

I have a tiny tarball with sources and build.xml available here:

http://dev.cuspycode.se/public/poolbugtest.tar.gz

Look in README.txt for further instructions. I made the example
as small as I could, it's very tiny, but there are a few steps
to go through since a database needs to be created etc.

I stumbled upon another thing while isolating this: it turns
out that having a ValidationQuery is important. I use the query
SELECT * FROM MYTABLE. When I remove this, the memory leak goes
away.

I also tested two more databases, Postgresql and Microsoft Azure
SQL. Like Derby before, neither of them showed any increase in
memory. So something strange is happening when the Mysql driver
and the Tomcat-JDBC pool are interacting via JPA.

--
Bjorn Danielsson
Cuspy Code AB


Romain Manni-Bucau <[hidden email]> wrote:

> ok so can you share a sample reproducing the issue please?
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/1/4 Bjorn Danielsson <[hidden email]>:
>> Romain Manni-Bucau <[hidden email]> wrote:
>>>
>>> just to be sure to understand:
>>>
>>> in a plain tomcat does StatementFinalizer replace stmt.close() to make
>>> the leak going away?
>>
>> Yes.
>>
>> --
>> Bjorn Danielsson
>> Cuspy Code AB
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

smithh032772
In reply to this post by Romain Manni-Bucau
Is this possibly related to the following discussion (which was
coincidentally discussed today as well on tomcat user list) ?

http://tomcat.10.n6.nabble.com/jdbc-pool-Transaction-left-open-by-the-connection-validation-mechanism-td4991758.html
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Romain Manni-Bucau
ok,

with https://issues.apache.org/jira/browse/TOMEE-703 (available
tomorrow on snapshot)

+

<Resource id="jdbc/poolbugtest" type="DataSource">
  DataSourceCreator tomcat
  JdbcDriver com.mysql.jdbc.Driver
  JdbcUrl jdbc:mysql://localhost:3306/poolbugtest
  ValidationQuery SELECT * FROM MYTABLE
  JtaManaged true
  jdbcInterceptors = StatementFinalizer
</Resource>

it should be better

can you check it please?


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2013/1/4 Howard W. Smith, Jr. <[hidden email]>:
> Is this possibly related to the following discussion (which was
> coincidentally discussed today as well on tomcat user list) ?
>
> http://tomcat.10.n6.nabble.com/jdbc-pool-Transaction-left-open-by-the-connection-validation-mechanism-td4991758.html
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Bjorn Danielsson
Many thanks Romain!

It looks like the memory leak is gone with the new snapshot.
The extra Mysql Statement and ResultSet instances disappeared
even without configuring JdbcInterceptors = StatementFinalizer.

But I enabled StatementFinalizer for a longer test. I'll leave it
running for a few days just to confirm that the leak is completely
plugged.

--
Bjorn Danielsson
Cuspy Code AB


Romain Manni-Bucau <[hidden email]> wrote:

> ok,
>
> with https://issues.apache.org/jira/browse/TOMEE-703 (available
> tomorrow on snapshot)
>
> +
>
> <Resource id="jdbc/poolbugtest" type="DataSource">
>   DataSourceCreator tomcat
>   JdbcDriver com.mysql.jdbc.Driver
>   JdbcUrl jdbc:mysql://localhost:3306/poolbugtest
>   ValidationQuery SELECT * FROM MYTABLE
>   JtaManaged true
>   jdbcInterceptors = StatementFinalizer
> </Resource>
>
> it should be better
>
> can you check it please?
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/1/4 Howard W. Smith, Jr. <[hidden email]>:
>> Is this possibly related to the following discussion (which was
>> coincidentally discussed today as well on tomcat user list) ?
>>
>> http://tomcat.10.n6.nabble.com/jdbc-pool-Transaction-left-open-by-the-connection-validation-mechanism-td4991758.html
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

smithh032772
Well, I thank you both. After this discussion and fix, I just had to
download the latest SNAPSHOT of TomEE plus (even though I am using embedded
Derby), and web app seems a bit faster 'tonight'. :)


On Sun, Jan 6, 2013 at 10:19 AM, Bjorn Danielsson <
[hidden email]> wrote:

> Many thanks Romain!
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Bjorn Danielsson
Update: Confirmed, everything looks good after running 46 hours.
I also started a second test yesterday using the same code but
Eclipselink instead of OpenJPA. It too looks good after 24 hours.

The only instances I could see increasing slowly were objects
called "compiledICHolderKlass", which I think are associated
with the inline cache of the Hotspot compiler. After some time
these instances stopped increasing, as expected.

--
Bjorn Danielsson
Cuspy Code AB


"Howard W. Smith, Jr." <[hidden email]> wrote:
> Well, I thank you both. After this discussion and fix, I just had to
> download the latest SNAPSHOT of TomEE plus (even though I am using embedded
> Derby), and web app seems a bit faster 'tonight'. :)
>
>
> On Sun, Jan 6, 2013 at 10:19 AM, Bjorn Danielsson <
> [hidden email]> wrote:
>
>> Many thanks Romain!
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Romain Manni-Bucau
Great!

thanks for the feedback. That's really appreciated.

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2013/1/8 Bjorn Danielsson <[hidden email]>:
> compiledICHolderKlass
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

smithh032772
I agree and I thank you both.
 On Jan 8, 2013 7:04 AM, "Romain Manni-Bucau" <[hidden email]> wrote:

> Great!
>
> thanks for the feedback. That's really appreciated.
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/1/8 Bjorn Danielsson <[hidden email]>:
> > compiledICHolderKlass
>
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Bertrand Guay-Paquet
In reply to this post by Bjorn Danielsson
Hi,

I got the same memory leak issue and found this thread. Before I did
however, I found the root of the problem in Tomcat.

The issue is here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54732

There is also a related TomEE bug which causes Tomcat's StatementCache
jdbc interceptor to always be used:
https://issues.apache.org/jira/browse/TOMEE-837

When at least one of these is fixed, the StatementFinalizer should not
be necessary since it is really a "patch" to solve broken interaction
with the jdbc connections and statements.

Regards,
Bertrand

On 03/01/2013 1:54 PM, Bjorn Danielsson wrote:

> Hi people,
>
> I get memory leaks from the built-in TomEE JDBC connection pool,
> using the default container-managed persistence and transactions.
>
> I have some code in a Singleton EJB that does, essentially, this:
>
>      @PersistenceUnit(unitName = "MyApp")
>      EntityManagerFactory emf;
>
>      @Schedule(second="*/10", minute="*", hour="*")
>      public void tickTock() {
>          EntityManager em = emf.createEntityManager();
>          em.find(MyTrivialEntity.class, 1);
>      }
>
> Every time tickTock() is invoked, jmap -histo:live reports objects
> being added permanently to the heap:
>
>   num     #instances         #bytes  class name
> ----------------------------------------------
> [...]
>   270:             6           1584  com.mysql.jdbc.JDBC4PreparedStatement
>   322:             6           1056  com.mysql.jdbc.JDBC4ResultSet
>
> These #instances and #bytes values increase at a steady pace,
> and if I leave it running long enough this causes OutOfMemory.
> The number of connections doesn't grow: both mysqladmin and jmap
> consistently report 3 simultaneous connections all the time.
>
> It doesn't matter if I use Eclipselink instead of OpenJPA.
>
> But the memory leak goes away if I change the database from Mysql
> to embedded Derby, so I assume there is some quirkiness in the
> Mysql driver that is involved.
>
> The memory leak also goes away if I revert to using commons-dbcp
> for the pool.
>
> MaxAge <N> is a workaround, but how do I choose <N> for any
> specific load? This is not an attractive solution.
>
> I searched a lot before I posted this, and I found recommendations
> that you should always close SQL Statements and ResultSets before
> returning connections to the pool. But I have to trust the container
> to do this when I am using JPA, right? Or am I missing something?
>
> Version info:
>
> apache-tomee-1.5.1-plus (I also tried today's 1.5.2 snapshot)
> mysql-connector-java-5.1.22
> jdk-7u9
>

Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Romain Manni-Bucau
be happy it is fixed ;)

+ if tomcat-jdbc bother you you can use commons dbcp

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/3/20 Bertrand Guay-Paquet <[hidden email]>

> Hi,
>
> I got the same memory leak issue and found this thread. Before I did
> however, I found the root of the problem in Tomcat.
>
> The issue is here:
> https://issues.apache.org/**bugzilla/show_bug.cgi?id=54732<https://issues.apache.org/bugzilla/show_bug.cgi?id=54732>
>
> There is also a related TomEE bug which causes Tomcat's StatementCache
> jdbc interceptor to always be used:
> https://issues.apache.org/**jira/browse/TOMEE-837<https://issues.apache.org/jira/browse/TOMEE-837>
>
> When at least one of these is fixed, the StatementFinalizer should not be
> necessary since it is really a "patch" to solve broken interaction with the
> jdbc connections and statements.
>
> Regards,
> Bertrand
>
>
> On 03/01/2013 1:54 PM, Bjorn Danielsson wrote:
>
>> Hi people,
>>
>> I get memory leaks from the built-in TomEE JDBC connection pool,
>> using the default container-managed persistence and transactions.
>>
>> I have some code in a Singleton EJB that does, essentially, this:
>>
>>      @PersistenceUnit(unitName = "MyApp")
>>      EntityManagerFactory emf;
>>
>>      @Schedule(second="*/10", minute="*", hour="*")
>>      public void tickTock() {
>>          EntityManager em = emf.createEntityManager();
>>          em.find(MyTrivialEntity.class, 1);
>>      }
>>
>> Every time tickTock() is invoked, jmap -histo:live reports objects
>> being added permanently to the heap:
>>
>>   num     #instances         #bytes  class name
>> ------------------------------**----------------
>> [...]
>>   270:             6           1584  com.mysql.jdbc.**
>> JDBC4PreparedStatement
>>   322:             6           1056  com.mysql.jdbc.JDBC4ResultSet
>>
>> These #instances and #bytes values increase at a steady pace,
>> and if I leave it running long enough this causes OutOfMemory.
>> The number of connections doesn't grow: both mysqladmin and jmap
>> consistently report 3 simultaneous connections all the time.
>>
>> It doesn't matter if I use Eclipselink instead of OpenJPA.
>>
>> But the memory leak goes away if I change the database from Mysql
>> to embedded Derby, so I assume there is some quirkiness in the
>> Mysql driver that is involved.
>>
>> The memory leak also goes away if I revert to using commons-dbcp
>> for the pool.
>>
>> MaxAge <N> is a workaround, but how do I choose <N> for any
>> specific load? This is not an attractive solution.
>>
>> I searched a lot before I posted this, and I found recommendations
>> that you should always close SQL Statements and ResultSets before
>> returning connections to the pool. But I have to trust the container
>> to do this when I am using JPA, right? Or am I missing something?
>>
>> Version info:
>>
>> apache-tomee-1.5.1-plus (I also tried today's 1.5.2 snapshot)
>> mysql-connector-java-5.1.22
>> jdk-7u9
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: JDBC connection pool memory leak

Bertrand Guay-Paquet
Indeed the TomEE side is fixed! (unless you use
PoolPreparedStatements=true and MaxOpenPreparedStatements>0)

And yes, with 1.5.1, using commons dbcp pooling makes the memory leak go
away.

Bertrand

On 20/03/2013 12:23 PM, Romain Manni-Bucau wrote:

> be happy it is fixed ;)
>
> + if tomcat-jdbc bother you you can use commons dbcp
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/3/20 Bertrand Guay-Paquet <[hidden email]>
>
>> Hi,
>>
>> I got the same memory leak issue and found this thread. Before I did
>> however, I found the root of the problem in Tomcat.
>>
>> The issue is here:
>> https://issues.apache.org/**bugzilla/show_bug.cgi?id=54732<https://issues.apache.org/bugzilla/show_bug.cgi?id=54732>
>>
>> There is also a related TomEE bug which causes Tomcat's StatementCache
>> jdbc interceptor to always be used:
>> https://issues.apache.org/**jira/browse/TOMEE-837<https://issues.apache.org/jira/browse/TOMEE-837>
>>
>> When at least one of these is fixed, the StatementFinalizer should not be
>> necessary since it is really a "patch" to solve broken interaction with the
>> jdbc connections and statements.
>>
>> Regards,
>> Bertrand
>>
>>
>> On 03/01/2013 1:54 PM, Bjorn Danielsson wrote:
>>
>>> Hi people,
>>>
>>> I get memory leaks from the built-in TomEE JDBC connection pool,
>>> using the default container-managed persistence and transactions.
>>>
>>> I have some code in a Singleton EJB that does, essentially, this:
>>>
>>>       @PersistenceUnit(unitName = "MyApp")
>>>       EntityManagerFactory emf;
>>>
>>>       @Schedule(second="*/10", minute="*", hour="*")
>>>       public void tickTock() {
>>>           EntityManager em = emf.createEntityManager();
>>>           em.find(MyTrivialEntity.class, 1);
>>>       }
>>>
>>> Every time tickTock() is invoked, jmap -histo:live reports objects
>>> being added permanently to the heap:
>>>
>>>    num     #instances         #bytes  class name
>>> ------------------------------**----------------
>>> [...]
>>>    270:             6           1584  com.mysql.jdbc.**
>>> JDBC4PreparedStatement
>>>    322:             6           1056  com.mysql.jdbc.JDBC4ResultSet
>>>
>>> These #instances and #bytes values increase at a steady pace,
>>> and if I leave it running long enough this causes OutOfMemory.
>>> The number of connections doesn't grow: both mysqladmin and jmap
>>> consistently report 3 simultaneous connections all the time.
>>>
>>> It doesn't matter if I use Eclipselink instead of OpenJPA.
>>>
>>> But the memory leak goes away if I change the database from Mysql
>>> to embedded Derby, so I assume there is some quirkiness in the
>>> Mysql driver that is involved.
>>>
>>> The memory leak also goes away if I revert to using commons-dbcp
>>> for the pool.
>>>
>>> MaxAge <N> is a workaround, but how do I choose <N> for any
>>> specific load? This is not an attractive solution.
>>>
>>> I searched a lot before I posted this, and I found recommendations
>>> that you should always close SQL Statements and ResultSets before
>>> returning connections to the pool. But I have to trust the container
>>> to do this when I am using JPA, right? Or am I missing something?
>>>
>>> Version info:
>>>
>>> apache-tomee-1.5.1-plus (I also tried today's 1.5.2 snapshot)
>>> mysql-connector-java-5.1.22
>>> jdk-7u9
>>>
>>>