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] Updated: (DERBY-3596) Creation of logical connections from a pooled connection causes resource leak on the server
Date Wed, 04 Jun 2008 11:27:45 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Kristian Waagan updated DERBY-3596:

    Attachment: derby-3596-5a-complex_skip_creds.diff

Patches 4a and 5a implements checking the credentials or skipping the SECCHK, respectively.
Note the change that the database object is not reset if we are dealing with a deferred reset
(creating a new logical connection on the client).

I tried three variants of the skip approach:
 - use reader.skipDss().
 - use while loop and reader.skipBytes(),but don't check anything.
 - use while loop and make sure no invalid code points are received (uploaded patch 5a).

I ran the regression tests with the check creds patch (4a) and the two first skip approaches.
Tests for the 5a patch is running now.

If I hear nothing, i think I'll go for patch 5a.

> 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,
derby-3596-4a-complex_check_creds.diff, derby-3596-5a-complex_skip_creds.diff, nofix-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