[CONJ-170] There is an memory leak in mariadb client, version 1.2.0 which is latest Created: 2015-07-22  Updated: 2015-09-16  Resolved: 2015-09-16

Status: Closed
Project: MariaDB Connector/J
Component/s: Other
Affects Version/s: 1.2.0
Fix Version/s: 1.3.0

Type: Bug Priority: Major
Reporter: Bae MunHwan Assignee: Diego Dupin
Resolution: Fixed Votes: 0
Labels: None
Environment:

java 1.7

Attachments: PNG File image-20150722120639.png     PNG File image-20150722120657.png     PNG File screenshot-1.png    
Issue Links:
Blocks
blocks CONJ-22 Java Client library does not support ... Closed
Relates
relates to CONJ-194 Memory handling Closed
Sprint: Sprint connector/j 1.3.0

 Description   


As you can see in the image which is attached,there is an memory leak in mariadb module.
Actually 5 part, which are mentioned below, are linked to memory leak.
1)org.mariadb.jdbc.MySQLStatement$1
2)org.mariadb.jdbc.internal.common.query.parameters.ParameterHolder
3)org.mariadb.jdbc.MySQLPreparedStatement
4)org.mariadb.jdbc.internal.common.query.MySQLParameterizedQuery
5)org.mariadb.jdbc.internal.common.query.parameters.LongParameter

When I figured out it, I have checked about some kinds of mistakes in my code. But, I could not find out any kinds of mistake to take place the memory leak.
In addition to that I checked mysql client, and there is no memory leak.
so I think there is some memory leak in mariadb java client.

 Comments   
Comment by Diego Dupin [ 2015-07-22 ]

Have you an extract of the code you are using (if you have isolated some problem) ?
Seeing the jprofiler data, the memory footprint see a lot of PrepareStatement instance (and associated object).
I will try to reproduce the problem.

Comment by Diego Dupin [ 2015-07-22 ]

After checking the memory footprint on my side, I looked in detail to your JProfiler images.

You will confimed what i'm thinking, but it seems that the footprint you send is after the launch of an application using ibatis, that has prepared a lot of queries in mapper XML Files.

The connector performs client preparation, not on server side.
This has several consequences, and concerning you case, having to keep queries in memory -> therefore have a higher memory footprint to MySQL connector in this case

This is one of the evolutions of the connector that is to be programmed quickly !

Comment by Diego Dupin [ 2015-09-16 ]

the problem has been reproduced and corrected in 1.3.0

Comment by Diego Dupin [ 2015-09-16 ]

Corrected in 1.3.0.
The problem come from the different buffer used to send data to server.
That has been simplified by using one ByteBuffer (even in compression mode) to avoid the creation intermediate array of byte

Generated at Thu Feb 08 03:13:41 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.