pub struct EventBusStats {
pub events_ingested: CachePadded<AtomicU64>,
pub events_dropped: CachePadded<AtomicU64>,
pub batches_dispatched: CachePadded<AtomicU64>,
pub events_dispatched: CachePadded<AtomicU64>,
pub shutdown_was_lossy: AtomicBool,
}Expand description
Event bus statistics.
PERF_AUDIT §1.2 — Counters are CachePadded so the
producer-hot events_ingested/events_dropped don’t false-
share with the batch-worker-hot
batches_dispatched/events_dispatched. Pre-fix all four sat
on 1-2 cache lines and every per-event fetch_add ping-ponged
the line between ingesting producers and the batch worker.
CachePadded<AtomicU64> derefs to AtomicU64, so external
callers using stats.events_ingested.load(...) work unchanged.
Fields§
§events_ingested: CachePadded<AtomicU64>Total events ingested.
events_dropped: CachePadded<AtomicU64>Events dropped due to backpressure.
batches_dispatched: CachePadded<AtomicU64>Batches dispatched to adapter.
Pre-fix this field was declared but never incremented anywhere
— flush()’s Phase 2 progress probe (bus.rs:815) read it as
“did the BatchWorker make progress this max_delay window?”,
observed 0 == 0, and always early-broke after a single
window. On Windows-class timer resolution the race against the
BatchWorker’s first recv_timeout tipped the wrong way for
flush_is_a_delivery_barrier regularly. Now incremented in
the BatchWorker spawn (after a successful dispatch_batch)
and in remove_shard_internal’s stranded-flush.
events_dispatched: CachePadded<AtomicU64>Total events dispatched to the adapter (sum of batch lengths
from successful on_batch calls). Companion to
batches_dispatched — by the time flush() returns,
events_dispatched + events_dropped == events_ingested. FFI
consumers can also use this to monitor end-to-end delivery.
shutdown_was_lossy: AtomicBoolSet to true if shutdown() / shutdown_via_ref() had to
proceed past the in-flight-ingest grace deadline (5 s) with
producers still mid-push. The stranded count is counted into
events_dropped (already; pre-fix), but shutdown returns
Ok(()) regardless — callers that need to distinguish
“clean shutdown” from “lossy shutdown” check this flag in
bus.stats() afterward (only meaningful for the
shutdown_via_ref path that doesn’t consume the bus).
Pre-fix the warning + events_dropped increment
were the only signal; Result<(), AdapterError> returned
Ok indistinguishable from a clean shutdown.