Fix HikariCP pool exhaustion

Free Spring Boot lab: fix HikariCP connection pool exhaustion after a traffic spike. Diagnose leaked JDBC connections in the browser — no sign-up.

API returns 503 after a traffic spike. Logs say Connection is not available, request timed out after 30000ms. Pool metrics sit at active=10, idle=0. This lab is the leaked JDBC connection — not “increase maximumPoolSize”.

HikariCP keeps a fixed pool of PostgreSQL connections. ReportService calls dataSource.getConnection() and never closes it on the exception path, so every export permanently borrows a slot. Under load the pool empties, servlet threads block for connectionTimeout, and the service looks down.

In the lab you read ReportService.java, match the symptoms (timeout after 30s, works at low traffic, fails under load), and pick leak / try-with-resources — not a heap bump or a Kubernetes restart. The fix is try-with-resources or JdbcTemplate so Spring returns the connection.

What you will cover

Related free labs and modules

Common questions

What causes HikariCP connection pool exhaustion in Spring Boot?

Borrowed JDBC connections that are never returned. A manual getConnection() without try-with-resources leaks a slot on every error path. The pool hits maximumPoolSize, new requests wait for connectionTimeout, and you see Connection is not available.

How do I tell a connection leak from a pool that is too small?

A small pool still shows idle connections at low traffic. A leak drives active count to the max and keeps it there after traffic drops. Hikari leakDetectionThreshold and connection-level metrics confirm unclosed connections.

Is this HikariCP lab free?

Yes. The HikariCP pool exhaustion lab is lifetime-free in the browser. No account, no credit card, and no time limit.

Free Spring Boot debug challenges · Free debug challenges · Java Spring Boot path · Create free account