Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sat, 31 May 2014 04:14:04 +0000 (UTC)
From: "Phil Steitz (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12373301.1183983553404.52591.1401509644801@arcas>
In-Reply-To: <JIRA.12373301.1183983553404@arcas>
References: <JIRA.12373301.1183983553404@arcas>
Subject: [jira] [Closed] (DBCP-229) Track callers of active connections for
 debugging
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/DBCP-229?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

Phil Steitz closed DBCP-229.
----------------------------


> Track callers of active connections for debugging
> -------------------------------------------------
>
>                 Key: DBCP-229
>                 URL: https://issues.apache.org/jira/browse/DBCP-229
>             Project: Commons Dbcp
>          Issue Type: New Feature
>            Reporter: Armin H=C3=A4berling
>             Fix For: 2.0
>
>
> Lately we got the following exception
> org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool=
 exhausted
>         at
> org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource=
.java:103)
>         at
> org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.jav=
a:540)
> The reason for that was that some piece of code opened a connection, but =
never closed it. Tracking the active connections (and the callers of the ge=
tConnection method) would it make it easier to find such erroneous code.
> One possible approach would be to add the connection returned by BasicDat=
aSource.getConnection together with the stacktrace in a Map holding all act=
ive connections. And removing the connection from the map during PoolableDa=
taSource.close().


--
This message was sent by Atlassian JIRA
(v6.2#6252)