Expand description
Rust port of the Java Platform registry + the manager-worker dispatch
(org.platformlambda.core.system.Platform / ServiceQueue / WorkerHandler).
Each route gets a manager task (the ServiceQueue analog) running the
FIFO reactive back-pressure state machine, and instances worker tasks
that pull work via ready signals:
- a worker announces
Ready(Java’sready:<route>#<n>bus signal), waits for one event, processes it, and announcesReadyagain — at most one in-flight event per worker; - the manager keeps a FIFO of ready workers. With no free worker it enters
buffering mode and spills events into the per-route
ElasticQueue(firstMEMORY_BUFFERevents in memory, overflow to segment files), draining one event per ready signal until the queue is empty — then the elastic queue closes and direct dispatch resumes; - the manager’s inbound mailbox is bounded
(
elastic.queue.dispatch.mailbox.size, default 1024, min 20): when it fills, senders await — back-pressure, not drops (the Java vthread-dispatch mailbox behavior).
Events are serialized (MsgPack) only when they cross into the elastic
queue — a deliberate divergence from Java, where every bus message is
already byte[]; in-process Rust moves the envelope for free, and the
on-disk record format stays byte-identical to the Java store.
register must be called within a Tokio runtime (managers/workers are
spawned tasks) — the analog of the Java platform’s Vert.x runtime
requirement. The manager runs the spill I/O inline on its own task, exactly
as Java runs it on the per-route dispatch virtual thread.
Structs§
- Function
Options interceptoris@EventInterceptor(the function receives the raw envelope —reply_to/cidintact — and replies manually; the worker sends no auto-reply on success, though a failure still routes toreply_to).- Platform
- The service registry: route name → manager + worker pool. Cheap to clone.