Default Fork‑Join Dispatcher vs. Pinned Dispatcher: Which Minimizes Idle Thread Cost for Low‑Traffic Akka Workloads?

Goal

Determine the most cost‑effective dispatcher configuration for an Akka application that experiences sporadic traffic, with the aim of minimizing idle thread overhead while maintaining acceptable latency.

Constraints & Uncertainty

The default fork‑join pool reuses threads across idle periods, but the exact minimum thread count it retains when traffic approaches zero is undocumented. A pinned dispatcher guarantees one thread per actor, simplifying debugging but potentially increasing idle resource consumption if the actor count is large. The trade‑off between these two documented dispatcher strategies remains unclear for near‑zero traffic scenarios.

Unresolved Questions

• What is the lowest number of threads the default fork‑join dispatcher maintains when traffic is negligible?
• Does the dispatcher automatically scale down to a single core under sustained idle periods, and how quickly does it recover when traffic resumes?