DistributedDataOptionsType
이 콘텐츠는 아직 번역되지 않았습니다.
DistributedDataOptionsType =
object
Defined in: src/crdt/DistributedDataOptions.ts:19
Plain options-object shape accepted by DistributedData.start.
Properties
Section titled “Properties”durableStore?
Section titled “durableStore?”
readonlyoptionaldurableStore?:DurableStateStore
Defined in: src/crdt/DistributedDataOptions.ts:69
Optional durable backend. When provided, the local CRDT view
is loaded from the store on preStart and re-saved after every
mutation (local update, gossip merge, delete). Without this,
DistributedData is purely in-memory — a full cluster restart
(deploy / outage) starts every replica empty.
The store is keyed by replica id, so each cluster member owns its own durable record. CRDT semantics handle convergence across replicas via gossip — durability is per-replica.
Plug in any of the existing DurableStateStore implementations:
InMemoryDurableStateStore for tests, the SQLite / Cassandra /
S3 / filesystem backends for production.
gossipInterval?
Section titled “gossipInterval?”
readonlyoptionalgossipInterval?:number
Defined in: src/crdt/DistributedDataOptions.ts:21
Period between gossip pushes. Default: 1 s.
maxPendingQuorumRequests?
Section titled “maxPendingQuorumRequests?”
readonlyoptionalmaxPendingQuorumRequests?:number
Defined in: src/crdt/DistributedDataOptions.ts:41
Most quorum requests (updateAsync + getAsync together) that may be
unsettled at once. A request past the cap is rejected outright instead
of being tracked. 0 disables the cap.
What the cap buys is a bound on the unsettled set itself: every entry holds a promise, a timer and a target set until its deadline passes, so an uncapped replicator under load accumulates all three. Refusing past the cap converts what would be a timeout storm into immediate, attributable rejections naming this knob (#140).
It is deliberately not justified by the mailbox underneath it any
more. That argument (sit an order of magnitude below the 10 000
drop-head bound, so the cap fires before the mailbox strands a
ddata-update envelope carrying the caller’s resolve / reject) was
wrong twice over: measurement in #1078 showed the promises stayed
unsettled either way, and #1148 removed the default bound entirely.
1 000 stands on the reasoning above, not on that one.
maxQuorumTimeout?
Section titled “maxQuorumTimeout?”
readonlyoptionalmaxQuorumTimeout?:number
Defined in: src/crdt/DistributedDataOptions.ts:53
Ceiling on the per-call timeoutMs of updateAsync / getAsync. A
larger caller-supplied value is clamped down to this one. 0 disables
the ceiling.
A pending quorum request holds a promise, a timer and a target set until its deadline passes, and it occupies one of the maxPendingQuorumRequests slots the whole time. Without a ceiling a single caller passing a multi-hour timeout parks those slots for hours and locks every later request out of the cap it never reached itself.