KamoCRM

SecurityService pool exhaustion caused liveness kills

FixSecurityService
Shipped
10 ஆகஸ்ட், 2026 அன்று 5:14 PM UTC
Author
Kamo
Commit
2fb944b

Hikari had no explicit maximum-pool-size, so it ran on the default of 10 while fronting org/rights lookups for every service and the internal site. Observed total=10 active=10 waiting=33, which stalled the /actuator/health db indicator to 18.8s; the 3s probe timeout then killed the pod (exit 137), 29 readiness failures over 154 minutes. That was surfacing to users as 'Upstream returned 500' on the internal site. Pool raised to 40 (safe now that YSQL Connection Manager multiplexes clients rather than one PostgreSQL backend each), and the probe timeouts relaxed from 3s to 10s.

All changes

Like what you see shipping?

All of it arrives in your workspace on its own. Start on the free plan and read this page again in a month.

Start Free ForeverView Pricing