Skip to main content

Module platform

Module platform 

Source
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’s ready:<route>#<n> bus signal), waits for one event, processes it, and announces Ready again — 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 (first MEMORY_BUFFER events 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§

FunctionOptions
interceptor is @EventInterceptor (the function receives the raw envelope — reply_to/cid intact — and replies manually; the worker sends no auto-reply on success, though a failure still routes to reply_to).
Platform
The service registry: route name → manager + worker pool. Cheap to clone.