geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dain Sundstrom (JIRA)" <j...@apache.org>
Subject [jira] Commented: (GERONIMO-2800) Connector Lazy Activation leaks managed connections
Date Tue, 06 Feb 2007 03:47:05 GMT

    [ https://issues.apache.org/jira/browse/GERONIMO-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470441
] 

Dain Sundstrom commented on GERONIMO-2800:
------------------------------------------

I think I have fixed this problem in revision 503969.  When connections are closed or destroyed
do not reassociate the connection again or throw an exception.  Instead simply invoke the
handle and let the handle throw the exception.

Please verify.

> Connector Lazy Activation leaks managed connections
> ---------------------------------------------------
>
>                 Key: GERONIMO-2800
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-2800
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: connector
>    Affects Versions: 2.0-M2
>            Reporter: Kevan Miller
>         Assigned To: Kevan Miller
>             Fix For: 2.0-beta1
>
>
> GERONIMO-2715 added "lazy connection" support to geronimo-connector. 
> I'm seeing problems where connectors are not being reused properly. The result is that
connectors are not being returned to their pool. Eventually, the pool of available connections
is exhausted and no more connections can be obtained from the pool.
> The basic scenario is:
> Connection c = ConnectionFactory.createConnection();
> c.close();
> c.close();
> Connection newC = ConnectionFactory.createConnection();
> newC.close();
> On the first c.close(), the connectionInfo is disassociated from the ConnectionProxy.
However, on the second c.close(), connectionInfo is re-associated with the ConnectionProxy.
However, since the second close() call is idempotent, the connection never leaves the pool.
When a new Connection is created, the connection is re-used from the pool, but has two ConnectionInfo's
being tracked as handles. This extra handle prevents the ConnectionInfo from ever being returned
to the pool.
> I'm a relative novice when it comes to our Connector implementation. It's possible that
I'm missing another point where the problem could be fixed. However, I don't see it. I'm also
worried about concurrency issues with the current approach.
> I plan on setting lazyConnect to false in the transaction-jta11 and client-transaction
configs. If there aren't ideas on fixing, I think we'll want to revert the lazy connection
code...
>   

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