Expand description
Resolution of the three HTTP handler-pool knobs (issue #574 slice 5).
The values are configurable through the standard precedence chain used elsewhere in the boot path:
flag > red_config > env > built-in default
Built-in defaults reproduce the hard-coded values from slices 1+2:
- max_handlers = (2 * num_cpus).clamp(8, 256)
- handler_timeout = 30_000 ms
- retry_after_secs = 5
Each knob is validated at parse time and at resolution time so a stale red_config value cannot corrupt the running server.
Structs§
- Http
Limits CliInput - CLI-layer input. Each pair holds the already-validated value coming
from a flag and from an env var, respectively. The resolver applies
the
flag > red_config > env > defaultprecedence using these inputs plus a config-store lookup. - Http
Limits Resolved - Resolved values after applying the full precedence chain. Stamped
into both the
RedDBServerand the startup log line.
Constants§
- DEFAULT_
HANDLER_ TIMEOUT_ MS - DEFAULT_
RETRY_ AFTER_ SECS - MAX_
RETRY_ AFTER_ SECS - MIN_
HANDLER_ TIMEOUT_ MS - Lower bound for
handler_timeout_ms. Anything below this is so short the deadline trips on healthy requests; we reject the value. - MIN_
RETRY_ AFTER_ SECS - Inclusive bounds for
retry_after_secs. Below 1s means clients hammer the server; above 30s means a transient overload looks like a permanent outage to load balancers.
Functions§
- default_
max_ handlers - Built-in default for
max_handlers. MatchesHttpConnectionLimiter::with_default_cap. - resolve_
http_ limits - Apply the
flag > red_config > env > defaultchain. - validate_
handler_ timeout_ ms - validate_
max_ handlers - Validate a
max_handlerscandidate from any source. Returns the value unchanged on success. - validate_
retry_ after_ secs