Tomcat JDBC pool reaches maxActive while abandoned connections await removal

Direct answer

Bound removeAbandonedTimeout by the longest legitimate transaction duration plus a safety margin, not by maxActive alone. Enable removeAbandoned, keep abandonWhenPercentageFull at 0 initially, and treat logAbandoned as a temporary diagnostic. I am assuming the Tomcat JDBC pool factory org.apache.tomcat.jdbc.pool.DataSourceFactory on Tomcat 8.5/9/10/11; attribute names and defaults vary by release, so verify them against the documentation for the deployed version.

Confirmed behavior vs likely diagnosis

• Confirmed: removeAbandoned must be true before any checked-out connection can be reclaimed.
• Confirmed: removeAbandonedTimeout is the primary age threshold. abandonWhenPercentageFull is a secondary utilization gate: when set greater than 0, cleanup runs only after utilization reaches that percentage of maxActive.
• Likely: maxActive exhaustion is caused by leaked checkouts that never return, eventually making the pool reject new requests. Confirm this with JMX before changing the timeout.

Safe initial bound without incident history

1. Derive the legitimate ceiling from transaction or statement timeouts, the longest batch job, report, or ETL step. Do not set the abandoned timeout below that ceiling.
2. Start conservatively at roughly twice the longest measured legitimate duration, then lower it gradually while monitoring pool exhaustion and active-transition metrics.
3. Ensure the timeout exceeds the application p99 transaction duration plus margin. If the p99 is unknown, measure it with APM or database logs before shortening the timeout.

<Resource name='jdbc/AppDB'
          factory='org.apache.tomcat.jdbc.pool.DataSourceFactory'
          type='javax.sql.DataSource'
          removeAbandoned='true'
          removeAbandonedTimeout='600'
          abandonWhenPercentageFull='0'
          logAbandoned='false' />

Replace 600 with the computed seconds. If your Tomcat build does not accept abandonWhenPercentageFull='0', omit it and verify the attribute in the version-specific documentation.

Should abandonWhenPercentageFull be tuned first?

No. Removal depends primarily on removeAbandoned plus removeAbandonedTimeout. Tune abandonWhenPercentageFull only after basic reclamation behavior is stable; use it to reduce sweep frequency when the pool is healthy, not as the primary leak control.

logAbandoned trade-off

logAbandoned preserves the borrowing stack trace so the log identifies the code path that failed to close the connection. That is valuable, but it adds per-checkout bookkeeping and logging cost during reclamation. In a high-concurrency web application, leave it disabled in steady-state production and enable it temporarily in staging or during a short diagnostic window.

Verification

• Monitor JMX numActive, numIdle, and pool size; compare peak active connections with maxActive.
• Confirm reclaimed connections appear before exhaustion and that legitimate transactions are not interrupted.
• Keep Tomcat JDBC settings in context.xml or server.xml; do not substitute Commons DBCP or HikariCP property names.

One diagnostic detail would change the recommendation: whether exhaustion occurs with numActive pinned near maxActive and numIdle near zero, or as short spikes that recover on their own.