pub struct Health(/* private fields */);Expand description
One listener’s accept-loop health: how to react to a failure, and what a supervisor outside the process can read back.
Cheap to clone; every clone shares one listener’s state. The listeners here
build their own and hand out a clone through their accept_health() method (as
does the relay’s web server), while an embedder driving its own listener
constructs one with new.
This owns the backoff rather than each loop inlining its own, which is the one place that indirection earns its keep: the classification above is the whole point of the pacing, and five listeners that each re-derive it will not agree for long.
Implementations§
Source§impl Health
impl Health
Sourcepub fn new(listener: &'static str) -> Self
pub fn new(listener: &'static str) -> Self
Track a listener reported under listener (the name used in logs and as a
metric label).
Sourcepub fn accepted(&self)
pub fn accepted(&self)
An accept succeeded: the listener is serving, so any stall is over and the next failure starts from the shortest delay again.
Sourcepub fn failed(&self, err: &Error) -> Option<Duration>
pub fn failed(&self, err: &Error) -> Option<Duration>
An accept failed: classify it, count it, log it, and return how long the loop should wait before asking again.
None means retry at once, which is what a Failure::Connection wants:
the queue entry was consumed, so the listener has already made progress.
Sourcepub fn failures(&self, failure: Failure) -> u64
pub fn failures(&self, failure: Failure) -> u64
Failed accepts of this class since the process started.
Cumulative and never reset, so a scrape that lands after the episode still
sees it. Classes are counted apart rather than totalled because they are not
comparable: Failure::Connection tracks how much junk traffic the node is
fielding, while a non-zero Failure::Exhausted means the process ran out of
something it needs to serve anyone.
Sourcepub fn stalled(&self) -> Option<Duration>
pub fn stalled(&self) -> Option<Duration>
How long the listener has been unable to accept, when a
Failure::Exhausted stall is in progress.
Only a successful accept clears it, so a listener with no traffic holds its last value rather than claiming a recovery it has no evidence for.