You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
compute: launch a second, interactive compute runtime
With `--interactive-compute-timely-config`, clusterd runs two compute runtimes in
one process: the first takes the `Maintenance` role, the second `Interactive`, and
both share the one sharing registry so a reader on worker `i` of either finds the
slot a publisher on worker `i` of the other filled. The two must span an equal
number of Timely peers, which the config preparation asserts, because the registry
pairs workers by ordinal and reads are sound only if both shard keys across the
same peer count. Without the flag the process runs a single `Solo` runtime and is
byte-unchanged from a deployment that has no second runtime.
One controller endpoint still fronts the replica. With two runtimes a
`Multiplexer` serves it, routing each command to the owning runtime and merging
responses; with one, the maintenance client builder serves it directly.
Shared fate is the read-hold mechanism. Both runtimes' worker and reader threads
are covered by the process-global panic hook installed at the top of `main`, so a
panic on either aborts the whole process. That bounds an interactive import's read
hold to the life of the replica without a lease, because there is no way for one
runtime to wedge while the other's holds continue. A subprocess test asserts the
abort, which cannot be observed from inside the panicking process.
`ClusterSpec::cluster_name` lets one process run two clusters of the same kind with
distinguishable tracing spans. The interactive runtime takes
`compute-interactive`; solo and maintenance keep the bare `compute` so
single-runtime logs are unchanged.
`enable_compute_interactive_runtime` is replica-scoped but resolved in
`environmentd`, because the controller decides `ServiceConfig::ports` before the
replica exists and so cannot read the value from the replica's `worker_config`.
`CatalogState::replica_scoped_bool` parses the override through the dyncfg rather
than `str::parse`, since a stored bool formats as `on`/`off`, which
`str::parse::<bool>()` rejects.
Off by default in production and in tests. Flipping it changes how a replica is
provisioned, so it is not a live toggle: a running replica keeps the layout it was
launched with.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments