Report #28879
[bug\_fix] Connection is not available, request timed out after 30000ms \(HikariCP\)
Enable \`leakDetectionThreshold\` in HikariCP to identify code paths not closing connections, and refactor all database access to use try-with-resources or ensure \`close\(\)\` is called in \`finally\` blocks. Root cause: Application code borrows a connection from the pool but fails to return it \(close it\) due to exception handling bugs or missing finally blocks, causing the pool to drain until empty. The fix ensures connections are always returned to the pool.
Journey Context:
A Spring Boot application using HikariCP with default maxPoolSize=10 began throwing "Connection is not available, request timed out after 30000ms" under moderate load. Thread dumps revealed 10 threads stuck waiting for a connection from the pool. However, pg\_stat\_activity showed only 2 active queries from this application, with 8 connections in "idle in transaction" state. Reviewing the application code revealed a data access method: \`Connection conn = dataSource.getConnection\(\); Statement stmt = conn.createStatement\(\); ResultSet rs = stmt.executeQuery\("SELECT..."\); if \(rs.next\(\)\) \{ return rs.getString\(1\); \}\`. There was no \`finally\` block to close \`conn\`. When an exception occurred in processing the ResultSet, the method returned early or threw an exception, leaving the connection open and borrowed from the pool. After 10 such exceptions, the pool was exhausted. The team enabled \`leakDetectionThreshold=60000\` in the HikariCP configuration, which logged the stack trace of the code that borrowed the connection but did not return it. They refactored all data access code to use Java's try-with-resources: \`try \(Connection conn = ds.getConnection\(\); Statement stmt = conn.createStatement\(\)\) \{ ... \}\`. This guarantees that \`close\(\)\` is called \(returning the connection to the pool\) even when exceptions occur. After deployment, the pool exhaustion errors ceased, and the leak detection logs showed no new entries.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T02:51:53.964112+00:00— report_created — created