db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3596) Creation of logical connections from a pooled connection causes resource leak on the server
Date Wed, 28 May 2008 13:01:45 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600462#action_12600462
] 

Knut Anders Hatlen commented on DERBY-3596:
-------------------------------------------

- I don't know if this can ever happen, but since we always set
deferredReset to false in parseEXCSAT() if appRequester is null, I
assume that it is possible that deferredReset is true when
parseEXCSAT() is called. As the code is now, it won't set
deferredReset to false if it's true when the method is called and it
is an XA request. Is this intended, or should deferredReset always be
set to the value of (appRequester != null && !appRequester.isXARequester())?


- I'm not sure I understand this comment:

+        // Reset the flag again. In sane builds it is used to avoid asserts, but
+        // we want to reset it as soon as possible to avoid masking real bugs.
+        this.deferredReset = false;

I don't see any asserts that check deferredReset, and I don't see how
it masks bugs.

- Is it safe to skip the user/password check at the end of
parseSECCHK() when processing a deferred reset? Earlier in that
method, the user id and password fields of the database object are
updated with whichever the SECCHK message contains, so even if the
Derby network client never changes the user id, could a malicious
client exploit this somehow?

> Creation of logical connections from a pooled connection causes resource leak on the
server
> -------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3596
>                 URL: https://issues.apache.org/jira/browse/DERBY-3596
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client, Network Server, Performance
>    Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>         Attachments: complex-fix-heap.png, ConnectionPoolingBug.java, derby-3596-1a-complex_approach.diff,
derby-3596-1b-complex_approach.diff, derby-3596-2a-simple_approach.diff, derby-3596-3a-test_cleanup.diff,
nofix-heap.png, simple-fix-heap.png
>
>
> When using ClientConnectionPoolDataSource and connection pooling, a new connection /
transaction is created for every new logical connection, and the resources are not freed /
cleaned up in the server. They are not even cleaned up when the physical connection (ClientPooledConnection)
is closed.
> A logical connection is obtained by invoking ClientPooledConnection.getConnection().
> I have observed that if you run the repro enough times against the same server, the number
of transaction in the transaction table will be reduced now and then. I believe this is garbage
collection, but I have not investigated the problem enough to tell for sure what's going on.
> I have also seen some locks not being freed, causing timeouts in some applications. I
don't have a repro for the lock problem at this time, but it is very likely related to this
issue.
> Note that XA connections are handled differently on the server, and do probably not have
this problem.

-- 
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