db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dyre Tjeldvoll (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3198) Using setQueryTimeout will leak sections
Date Thu, 29 Nov 2007 11:30:43 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546665
] 

Dyre Tjeldvoll commented on DERBY-3198:
---------------------------------------

If we go for the separate member variable option; do we really need to free this Section?
If/when we start using this to cache session data, that Section 
will be needed for every message, so requesting it and freeing it each time is just going
to be extra work, isn't it? Or would that have some other drawback that I'm not seeing? I'm
running the tests with this change now, to see how it works.

> Using setQueryTimeout will leak sections 
> -----------------------------------------
>
>                 Key: DERBY-3198
>                 URL: https://issues.apache.org/jira/browse/DERBY-3198
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, Network Client
>    Affects Versions: 10.3.1.4
>            Reporter: Dyre Tjeldvoll
>            Assignee: Dyre Tjeldvoll
>         Attachments: derby-3198.v1.diff, derby-3198.v2.diff, repro.diff
>
>
> The implementation of setQueryTimeout relies on NetStatementReply.writeSetSpecialRegister()
which will allocate a dynamic section when called. No reference to this Section object is
kept, and so Section.free() never gets called on it. Executing the same statment repeatedly
with a query timeout set results in the client driver throwing an exception because the number
of Sections exceeding 32000.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message