tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: JDBC connection pool memory leak
Date Fri, 04 Jan 2013 12:28:21 GMT
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 <bjorn-apache@lists.cuspycode.com>:
> 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 <rmannibucau@gmail.com> 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. <smithh032772@gmail.com>:
>>> 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 <
>>> bjorn-apache@lists.cuspycode.com> 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.
>>>>

Mime
View raw message