[jira] [Comment Edited] (IGNITE-11524) Memory leak caused by executing a jdbc prepared statement

["Taras Ledkov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-11524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16795035#comment-16795035 ] 

Taras Ledkov edited comment on IGNITE-11524 at 3/18/19 1:59 PM:
----------------------------------------------------------------

[~vozerov]
1. Fixed,
2. {{JdbcThinConnection#stmts}} is cleared on close. I guess the statements shouldn't close explicitly on connection close:
- The object on server side are cleared by {{onDisconnect}}. 
- On client side {{JdbcThinStatement#isClosed}} check connection state.
- It takes additional  time on close to send not useful close commands.

I guess clear {{JdbcThinConnection#stmts}} is enough for decrease memory pressure when {{JdbcThinConnection}}s leak at user code.
We have to nullify the content of the {{JdbcThinStatement}} to reduce memory pressure  when {{JdbcThinStatement}}s leak at user code.


was (Author: tledkov-gridgain):
[~vozerov]
1. Fixed,
2. {{JdbcThinConnection#stmts}} is cleared on close. I guess the statements shouldn't close explicitly on connection close:
- The object on server side are cleared by {{onDisconnect}}. 
- On client side {{JdbcThinStatement#isClosed}} check connection state.

I guess clear {{JdbcThinConnection#stmts}} is enough for decrease memory pressure when {{JdbcThinConnection}}s leak at user code.
We have to nullify the content of the {{JdbcThinStatement}} to reduce memory pressure  when {{JdbcThinStatement}}s leak at user code.

> Memory leak caused by executing a jdbc prepared statement
> ---------------------------------------------------------
>
>                 Key: IGNITE-11524
>                 URL: https://issues.apache.org/jira/browse/IGNITE-11524
>             Project: Ignite
>          Issue Type: Bug
>          Components: jdbc, sql
>            Reporter: Pavel Vinokurov
>            Assignee: Taras Ledkov
>            Priority: Blocker
>             Fix For: 2.8
>
>         Attachments: PreparedStatementOOMReproducer.java
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Executing a prepared statement multiple times lead to OOM.
> VisualVM indicates that heap contains  a lot of JdbcThinPreparedStatament objects.
> The reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)