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