You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Graham Leggett <mi...@sharp.fm.INVALID> on 2025/11/16 10:51:14 UTC
How do I determine the origin of database connection pool leaks?
Hi all,
I have a tomcat9 web application that is leaking connections, and I need to detect where the leaks are occurring. This is surprisingly difficult.
The leak is reproducible, and occurs in a controlled test environment, so the vast majority of advice out there about monitoring database connections isn't useful - I know there is a leak. The codebase is large, so the "look at the codebase" advice doesn't work.
The exceptions I get tell me all about the straw that broke the camel's back, but none of that is useful - what I need to know at that point is what else is on the camel's back.
Is there a mechanism that exists where you can trigger a dump of the stack traces of all database connections currently open and where they were opened? Remember - in my case this is a reproducible leak in a controlled test environment, so I don't have the problem of a live system or filtering out noise.
This isn't working for me, I see no stack traces related to abandoned connections:
<Resource auth="Container" driverClassName="org.postgresql.Driver" factory="org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory" logAbandoned="true" maxIdle="5" maxTotal="5" maxWaitMillis="10000" name="" password="" type="javax.sql.DataSource" url="" username="" removeAbandonedOnBorrow="true" removeAbandoned="true" removeAbandonedTimeout="10" />
Is there a breakpoint I can stop the code at, or a signal I can send?
Regards,
Graham
--
Re: How do I determine the origin of database connection pool leaks?
Posted by Zdeněk Henek <vr...@gmail.com>.
The supsectTimeout is giving you same information to fix connection
leak as the logAbandoned,
there is same flag for abandoned timeout see removeAbandonedTimeout
I use these flags (among others but not important to fix the
connection leak) removeAbandoned="true" removeAbandonedTimeout="900"
logAbandoned="true" abandonWhenPercentageFull="0" suspectTimeout="400"
where 900 means 900 seconds till connection is marked as abandoned and
removed from connection pool, abandonWhenPercentageFull means remove
abandoned connections immediately, suspectTimeout is to write
additional warnings before the connection is abandoned.
There are options to configure additional interceptors: jdbcInterceptors=
see in the link I sent before
ConnectionState
StatementFinalizer
ResetAbandonedTimer
QueryTimeoutInterceptor(queryTimeout=milliseconds)
SlowQueryReport(threshold=milliseconds)
Just remainder I am using the
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" I am not sure
what is available for the DBCP jdbc pool.
Regards,
Zdenek
On Mon, Nov 17, 2025 at 9:58 AM Graham Leggett <mi...@sharp.fm.invalid> wrote:
>
> On 16 Nov 2025, at 12:01, Zdeněk Henek <vr...@gmail.com> wrote:
>
> > I don't use org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory
> >
> > but attribute logAbandoned="true"
> >
> > should log stacktrace of the place which allocated the connection into
> > catalina.out (in linux, windows may use different log file in logs
> > directory or standard output, depends on configuration).
> > This stacktrace leads to your code where you have to fix the connection
> > leak. The message is warning not an error and part of the message is this:
> >
> > Connection has been abandoned PooledConnection
> >
> >
> > I use this Tomcat built in jdbc
> > pool factory="org.apache.tomcat.jdbc.pool.DataSourceFactory". I would
> > suggest switching to the Tomcat JDBC pool if you really don't see any
> > stacktrace with abandoned connections. More documentation is here
> > https://tomcat.apache.org/tomcat-9.0-doc/jndi-datasource-examples-howto.html
> >
> > The leaked connection detection works this way:
> > 1. request is sent to Tomcat web application and db connection is
> > allocated (if needed)
> > 2. connection is used
> > 3. and should be returned
> >
> > Tomcat knows which connections are allocated and after timeout it marks the
> > connection and stop using the db connection. Now is logged the warning
> > connection has been abandoned. There is no way to get breakpoint to the
> > place where the connection is leaked and you don't need it. Use the
> > stacktrace after message Connection has been abandoned, there is the place
> > you need to fix leaking.
>
> Thank you for the explanation, it's very useful.
>
> What I eventually found that made a difference was the suspectTimeout option, like this:
>
> suspectTimeout="10"
>
> It seems to be the missing step in most online howtos about this.
>
> What it eventually revealed was some code that committed a transaction using a mechanism that didn't take the pool into account, thus leak.
>
> Regards,
> Graham
> --
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How do I determine the origin of database connection pool leaks?
Posted by Graham Leggett <mi...@sharp.fm.INVALID>.
On 16 Nov 2025, at 12:01, Zdeněk Henek <vr...@gmail.com> wrote:
> I don't use org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory
>
> but attribute logAbandoned="true"
>
> should log stacktrace of the place which allocated the connection into
> catalina.out (in linux, windows may use different log file in logs
> directory or standard output, depends on configuration).
> This stacktrace leads to your code where you have to fix the connection
> leak. The message is warning not an error and part of the message is this:
>
> Connection has been abandoned PooledConnection
>
>
> I use this Tomcat built in jdbc
> pool factory="org.apache.tomcat.jdbc.pool.DataSourceFactory". I would
> suggest switching to the Tomcat JDBC pool if you really don't see any
> stacktrace with abandoned connections. More documentation is here
> https://tomcat.apache.org/tomcat-9.0-doc/jndi-datasource-examples-howto.html
>
> The leaked connection detection works this way:
> 1. request is sent to Tomcat web application and db connection is
> allocated (if needed)
> 2. connection is used
> 3. and should be returned
>
> Tomcat knows which connections are allocated and after timeout it marks the
> connection and stop using the db connection. Now is logged the warning
> connection has been abandoned. There is no way to get breakpoint to the
> place where the connection is leaked and you don't need it. Use the
> stacktrace after message Connection has been abandoned, there is the place
> you need to fix leaking.
Thank you for the explanation, it's very useful.
What I eventually found that made a difference was the suspectTimeout option, like this:
suspectTimeout="10"
It seems to be the missing step in most online howtos about this.
What it eventually revealed was some code that committed a transaction using a mechanism that didn't take the pool into account, thus leak.
Regards,
Graham
--
Re: How do I determine the origin of database connection pool leaks?
Posted by Zdeněk Henek <vr...@gmail.com>.
HI Graham,
I don't use org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory
but attribute logAbandoned="true"
should log stacktrace of the place which allocated the connection into
catalina.out (in linux, windows may use different log file in logs
directory or standard output, depends on configuration).
This stacktrace leads to your code where you have to fix the connection
leak. The message is warning not an error and part of the message is this:
Connection has been abandoned PooledConnection
I use this Tomcat built in jdbc
pool factory="org.apache.tomcat.jdbc.pool.DataSourceFactory". I would
suggest switching to the Tomcat JDBC pool if you really don't see any
stacktrace with abandoned connections. More documentation is here
https://tomcat.apache.org/tomcat-9.0-doc/jndi-datasource-examples-howto.html
The leaked connection detection works this way:
1. request is sent to Tomcat web application and db connection is
allocated (if needed)
2. connection is used
3. and should be returned
Tomcat knows which connections are allocated and after timeout it marks the
connection and stop using the db connection. Now is logged the warning
connection has been abandoned. There is no way to get breakpoint to the
place where the connection is leaked and you don't need it. Use the
stacktrace after message Connection has been abandoned, there is the place
you need to fix leaking.
Regards,
Zdenek
On Sun, Nov 16, 2025 at 10:54 AM Graham Leggett <mi...@sharp.fm.invalid>
wrote:
> Hi all,
>
> I have a tomcat9 web application that is leaking connections, and I need
> to detect where the leaks are occurring. This is surprisingly difficult.
>
> The leak is reproducible, and occurs in a controlled test environment, so
> the vast majority of advice out there about monitoring database connections
> isn't useful - I know there is a leak. The codebase is large, so the "look
> at the codebase" advice doesn't work.
>
> The exceptions I get tell me all about the straw that broke the camel's
> back, but none of that is useful - what I need to know at that point is
> what else is on the camel's back.
>
> Is there a mechanism that exists where you can trigger a dump of the stack
> traces of all database connections currently open and where they were
> opened? Remember - in my case this is a reproducible leak in a controlled
> test environment, so I don't have the problem of a live system or filtering
> out noise.
>
> This isn't working for me, I see no stack traces related to abandoned
> connections:
>
> <Resource auth="Container" driverClassName="org.postgresql.Driver"
> factory="org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory"
> logAbandoned="true" maxIdle="5" maxTotal="5" maxWaitMillis="10000" name=""
> password="" type="javax.sql.DataSource" url="" username=""
> removeAbandonedOnBorrow="true" removeAbandoned="true"
> removeAbandonedTimeout="10" />
>
> Is there a breakpoint I can stop the code at, or a signal I can send?
>
> Regards,
> Graham
> --
>
>
Re: How do I determine the origin of database connection pool leaks?
Posted by Rob Sargent <rs...@xmission.com>.
> On Nov 16, 2025, at 3:52 AM, Graham Leggett <mi...@sharp.fm.invalid> wrote:
>
> Hi all,
>
> I have a tomcat9 web application that is leaking connections, and I need to detect where the leaks are occurring. This is surprisingly difficult.
>
> The leak is reproducible, and occurs in a controlled test environment, so the vast majority of advice out there about monitoring database connections isn't useful - I know there is a leak. The codebase is large, so the "look at the codebase" advice doesn't work.
>
> The exceptions I get tell me all about the straw that broke the camel's back, but none of that is useful - what I need to know at that point is what else is on the camel's back.
>
> Is there a mechanism that exists where you can trigger a dump of the stack traces of all database connections currently open and where they were opened? Remember - in my case this is a reproducible leak in a controlled test environment, so I don't have the problem of a live system or filtering out noise.
>
> This isn't working for me, I see no stack traces related to abandoned connections:
>
> <Resource auth="Container" driverClassName="org.postgresql.Driver" factory="org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory" logAbandoned="true" maxIdle="5" maxTotal="5" maxWaitMillis="10000" name="" password="" type="javax.sql.DataSource" url="" username="" removeAbandonedOnBorrow="true" removeAbandoned="true" removeAbandonedTimeout="10" />
>
> Is there a breakpoint I can stop the code at, or a signal I can send?
>
So the code base is opening connections and not closing them. Assuming this is a java environment you might need to wrap every connection call in a “try-with-resource” block to get a guaranteed close.
Can you narrow your tests to find the culprit(s)?
> Regards,
> Graham
> --
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org