db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (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 15:07:45 GMT

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

Kristian Waagan commented on DERBY-3596:

- 1) I moved the reset to before "if (appRequester != null)". It should be true for the shortest
time possible, but it must survive for a few iterations in the processCommands loop after
it has been set to true.

- 2) Sorry, I was at bit unclear. If you look at the end of the method processCommands, you
see this inside a SanityManager.DEBUG block:

    if (!this.deferredReset && pbsd != null) {

    This assert fails because of the connection reset I do. When the PBSD is written, we're
on track again and the flag can be reset and we execute the assert again for later iterations
in the processCommands loop. This workaround is required due to the "hackyness" of the fix...

- 3) No, I don't believe it is entirely safe to skip the user/password check. However, that
code is what creates the new connections, which is what we want to avoid. The credentials
are verified by actually connecting to the database. Some options:
    a) Make an extra connection attempt to verify credentials.
    b) Hang on to the credentials made during the initial connection and see if they have
changed for the deferred resets.

    Note that our driver had the functionality to change the credentials, but it doesn't anymore.
So I suppose the ability to exploit this depends on if a malicious client can "take over the
TCP-IP pipe" and act as the initial user. The new user credential won't take effect.
    For the general case, this will cause some overhead, and it is my opinion that the driver
shouldn't send this "reconnection sequence" at all. I'll try to implement option b) in the
next patch, along with some more comments and references to the Jira issue.

> Creation of logical connections from a pooled connection causes resource leak on the
> -------------------------------------------------------------------------------------------
>                 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:,,,,
>            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
> 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.

View raw message