Lazier Monos: act on first request rather than onSubscribe #2913
Labels
type/enhancement
A general enhancement
warn/behavior-change
Breaking change of publicly advertised behavior
wide-change
Milestone
Comments
simonbasle
added
type/enhancement
OlegDokuka
added a commit
that referenced
this issue
Aug 3, 2022
This commit changes 4 broad categories of Mono operators to be lazier and only start requesting from their upstream once they've been themselves requested. Previously, the request to upstream would happen immediately upon receiving the Subscription (in `onSubscribe`). The first category of Monos is the one where the upstream is a Flux that gets aggregated into a Mono, such as `MonoCollectList`, `MonoCount` but also `MonoAll` or `MonoElementAt`... These Mono now all inherit a common `BaseFluxToMonoOperator` which track two states as bits in a single volatile: request status (true/false) and completed status (true/false). It uses a non-volatile boolean hasRequest as a shortcut to ignore any request past the first one. Note that for now these implementations do declare a `Fuseable` trait, but they always negotiate fusion `NONE`. It is kept as a future possible improvement that they would all support SYNC fusion. The second category is Monos that combine multiple sources, like `MonoZip` or `MonoWhen`. A single volatile long-based state machine is used to coordinate the multiple inners and track which inner has made the first request. The third category is ParallelFlux-to-Mono operators, mixing the above two aspects: aggregating values and combining multiple sources (rails). Some of these can benefit from the `BaseFluxToMonoOperator` approach. The last category is sources like `MonoSupplier` or `MonoCallable`. Often the functional interface representing the logic would be run in `onSubscribe` directly, but making it lazier implies the creation of dedicated `Subscription` implementations now. Fixes #2913. Signed-off-by: Oleh Dokuka <odokuka@vmware.com> Co-authored-by: Simon Baslé <sbasle@vmware.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Most
Monos currently consider thatonSubscribeequatesrequest.They're still lazy, in the sense that not subscribing to a
Monodoesn't trigger its processing, but not always exactly adhering to backpressure when no initial request is made downstream.This issue turns vanilla core
Monos into truly lazy ones by moving processing fromonSubscribeto firstrequest.Some particular
Monooperators might need to retain their current behavior, in which case they should be listed below:The text was updated successfully, but these errors were encountered: