Pinned pipelined oplog applier in-flight backpressure and publication boundaries

Parent: Replication flow-control tickets and majority-commit lag diagnosis · Published reference · snapshot 2026-11-02

↓ Facts as markdown all context files

Source-anchored research for Pinned pipelined oplog applier in-flight backpressure and publication boundaries. Run status: COMPLETED.

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

How it works

The tracked byte total is serialized dispatched-operation size, not an accounting of all process allocations. The caller has already built vectors and work items before the capacity wait; the tracker owns original entries, derived entries and metadata, and a popped batch remains available to the publication callback after its bytes have been subtracted. These boundaries do not establish a hard process-memory ceiling. (high confidence) [source 1] [source 2] [source 3] [source 4]
Admission checks the existing FIFO count and bytes before adding the incoming batch; `backpressureNecessary` triggers only on a strictly positive excess in either dimension. Equality admits another batch, so an insertion can overshoot either configured threshold and the next insertion waits if the existing count or bytes still exceed a threshold when it checks admission. The tracker fixture admits four batches of `300` bytes with limits `3` batches and `900` bytes, then blocks the fifth; it covers count-only, byte-only and combined limits. (high confidence) [source 1] [source 2]
Explicit tracker `shutdown` sets `_shutdown`, notifies the consumer and broadcasts to capacity waiters. A dispatcher already blocked in `addBatch` returns `nullptr` on observing shutdown, and the caller returns before enqueuing worker items. The shutdown-capacity fixture asserts that a blocked third insertion wakes and returns `nullptr`; it does not establish that calling `addBatch` after shutdown is permitted, because entry asserts `!_shutdown`. (high confidence) [source 1] [source 2] [source 3]
This tracker applies queue-count and serialized-byte backpressure while registering batches. In the same pinned caller, `applyWorkItem` explicitly says oplog application must not wait on execution tickets or flow control and installs exempt admission priority. The in-flight signal therefore must not be described as evidence of equivalent primary flow-control ticket behavior. (high confidence) [source 1] [source 2]

Problems, failure modes and limitations

Worker completion decrements a batch-specific atomic remaining-worker counter; the final worker notifies the consumer. Only a zero-counter front batch can pop, so a completed later batch cannot release its tracked bytes while an earlier batch remains incomplete. The fixture completes the second batch first and asserts that no pop occurs until the first batch finishes. The completion handler itself does not subtract tracked bytes or notify the capacity condition variable. (high confidence) [source 1] [source 2]
The pinned IDL says hysteresis waits until a value “dips below” the product, whereas the implementation allows equality to the floored reduced limits and the fixture describes “on/below lower limit” as unblocked. The implementation and fixture therefore give the precise inclusive boundary for this pin. (high confidence) [source 1] [source 2] [source 3]
SERVER-136053 describes a separate shutdown-propagation bug in which returning from dispatch does not stop the outer run loop. The pinned caller still contains TODOs to propagate shutdown failure to `_run` and continues after an unsuccessful drain in the exhausted-batch path. This description is separate from the fixture that directly shuts down the tracker to wake a capacity wait; no mutable issue status is needed for that distinction. (high confidence) [source 1] [source 2] [source 3]

Comparisons and alternatives

`popCompletedBatch` removes the FIFO front, subtracts its `batchBytes`, sets `_advancerBusy` and notifies `_capacityCv` under the tracker mutex. Capacity is therefore released at pop rather than at worker completion or publication completion; the popped batch can still retain its backing objects during publication. (high confidence) [source 1] [source 2]
Worker abandonment is a different path from explicit tracker shutdown: `onWorkerAbandonment` marks `_hasAbandonedBatch` and notifies idle waiters, but does not notify `_capacityCv` or make the capacity predicate test abandonment. `waitUntilIdle` then returns false rather than successful idle. The abandonment fixture leaves the worker counter nonzero and asserts that neither its batch nor its successor publishes. Thus the explicit-shutdown capacity fixture does not prove that abandonment alone releases a blocked dispatcher. (high confidence) [source 1] [source 2] [source 3] [source 4]
The caller preserves the original batch publication boundary even when no operations route to workers by registering a zero-worker batch. The zero-worker fixture requires that synthetic boundary to wait behind an earlier incomplete batch, rather than bypassing FIFO order. (high confidence) [source 1] [source 2]
The release predicate requires both existing queue dimensions to be at or below their reduced thresholds, regardless of which dimension first caused the wait. It returns early for shutdown. The fixture runs a tight count cap, a tight byte cap, and both caps together; its joint case moves count and bytes together, rather than independently isolating each dimension while blocked. (high confidence) [source 1] [source 2]
SERVER-134780 frames its byte signal as bounding memory held by dispatched-but-unapplied operations. The pinned caller and tracker narrow that description to serialized dispatched-operation accounting with pre-append threshold checks and release at FIFO pop. Read the design’s memory language with those implementation boundaries, rather than as an exact process-memory ceiling. (high confidence) [source 1] [source 2] [source 3] [source 4]

Facts and statements

In the pinned development source, the caller builds writer vectors before registration and computes `batchBytes` by summing `getRawObjSizeBytes()` for every dispatched `applierOp` in each nonempty writer vector. It passes that sum to `addBatch` together with ownership of the original and derived entries before enqueueing worker items. A null registration result returns before enqueueing; even a zero-participant batch retains its original publication boundary. (high confidence) [source 1] [source 2]
The hysteresis fixture uses per-batch bytes `300`, factor `0.5`, and tight maxima `3` batches and `900` bytes. It admits four batches before blocking the fifth; popping to three and then two leaves the dispatcher blocked, while popping to one permits it to proceed. Its comments identify reduced limits as floor of the products, giving one batch and `450` bytes. These are source fixture assertions, not performance measurements. (high confidence) [source 1] [source 2]
The pinned IDL exposes `pipelinedApplierMaxInflightBatches`, `pipelinedApplierMaxInflightBytes` and `pipelinedApplierHysteresisFactor` at startup and runtime. A blocked `addBatch` reloads all three on every wait-predicate evaluation and recomputes its lower thresholds. The wait uses notifications and timed waits before a final unbounded wait; this supports reevaluation of changed values, not an unconditional promise that setting a parameter immediately wakes the dispatcher. (high confidence) [source 1] [source 2]
At this development pin, the IDL declares startup/runtime atomic thresholds named `pipelinedApplierMaxInflightBatches` and `pipelinedApplierMaxInflightBytes`, each validated at least `1`, with source defaults `256` and `1024LL * 1024 * 1024`. It declares `pipelinedApplierHysteresisFactor` with source default `0.5` and validation greater than `0.0` and at most `1.0`. These are declarations at the cited development pin; they do not establish a released-version default. (low confidence) [source]
Queue capacity release and publication completion are different boundaries. `popCompletedBatch` releases tracked capacity before the advancer invokes its publication callback; `onBatchPublished` clears the busy flag afterward. Normal idle requires both an empty queue and a nonbusy advancer. The tracker fixture asserts that an empty but already-popped queue remains busy until publication finishes. (high confidence) [source 1] [source 2] [source 3]
The caller waits for worker-pool idle before tracker publication idle. Its publication callback invokes `setMyLastAppliedOpTimeAndWallTimeForward` and `signalOplogWaiters()`. The advancer invokes that callback before `onBatchPublished`, so worker application, publication and a successful drain barrier are separate source-defined boundaries. (high confidence) [source 1] [source 2] [source 3]
Advancer shutdown first waits for idle or abandonment, then shuts the tracker down and joins its thread. The publication fixture deliberately stalls a callback, successfully adds and completes another batch, and asserts that shutdown remains unfinished until the callback is released. A second fixture abandons a later batch during an earlier publication and still requires the active publisher to finish before the join returns. (high confidence) [source 1] [source 2]
Planning and implementation use different parameter contracts: the SERVER-135581 description proposes `pipelinedOplogApplierMaxInflightBatches` with zero disabling its signal and suggests a possible drain/restart; the pinned IDL declares `pipelinedApplierMaxInflightBatches` with a minimum of one, while the tracker reloads thresholds during its wait. These are attributed source positions, not interchangeable configuration instructions. (high confidence) [source 1] [source 2] [source 3]

Children

No children recorded.

← the whole tree · 3D view· how to read this page