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 <[email protected]> wrote: > > On 16 Nov 2025, at 12:01, Zdeněk Henek <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
