Disable fusion in MonoSubscriber #3245
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
UgiR
commented
Oct 23, 2022
| @@ -58,15 +58,17 @@ public class FluxDoOnEachTest { | |||
| void doOnEachAsyncFusionDoesntTriggerOnNextTwice() { | |||
| List<String> signals = new ArrayList<>(); | |||
| StepVerifier.create(Flux.just("a", "b", "c") | |||
| .collectList() | |||
| .limitRate(3) | |||
There was a problem hiding this comment.
Switched to arbitrary operator that satisfies .expectFusion(Fuseable.ASYNC)
|
Need to fix some tests that depended on certain operators being fuseable |
OlegDokuka
approved these changes
Oct 25, 2022
|
@chemicL this PR seems to have been merged on a maintenance branch, please ensure the change is merge-forwarded to intermediate maintenance branches and up to |
|
@UgiR Thank you for the contribution! It was now merged. Would you care to follow up with another that removes mentions of fusion in the comments of MonoSubscriber implementation? |
chemicL
added a commit
that referenced
this pull request
Oct 27, 2022
|
@chemicL Yes will clean this up in the next few days -- must have missed it, thanks! |
chemicL
pushed a commit
that referenced
this pull request
Oct 31, 2022
simonbasle
added a commit
to reactor/reactor-addons
that referenced
this pull request
Nov 8, 2022
In reactor-core, `Operators.MonoSubscriber` has stopped implementing ASYNC fusion as a base. It continues to be compatible with Fuseable publishers but now by default only negotiates `Fuseable.NONE`. Some RxJava adapter classes don't really have a way of propagating the fusion up to RxJava and used to rely on the default ASYNC capability of MonoSubscriber, testing that `requestFusion` would indeed negotiate that. Now that it negotiates NONE, said tests fail. This commit removes the tests and adds a FIXME as a more in depth follow up to this issue (where we can evaluate if it makes sense to keep the publishers Fuseable). See reactor/reactor-core#3245.
simonbasle
added a commit
to reactor/reactor-addons
that referenced
this pull request
Nov 8, 2022
In reactor-core, `Operators.MonoSubscriber` has stopped implementing ASYNC fusion as a base. It continues to be compatible with Fuseable publishers but now by default only negotiates `Fuseable.NONE`. Some RxJava adapter classes don't really have a way of propagating the fusion up to RxJava and used to rely on the default ASYNC capability of MonoSubscriber, testing that `requestFusion` would indeed negotiate that. Now that it negotiates NONE, said tests fail. This commit removes the tests and adds a FIXME as a more in depth follow up to this issue (where we can evaluate if it makes sense to keep the publishers Fuseable). Also update to latest 3.4.x core snapshot. See reactor/reactor-core#3245.
violetagg
added a commit
to reactor/reactor-kotlin-extensions
that referenced
this pull request
Nov 8, 2022
In reactor-core, `Operators.MonoSubscriber` has stopped implementing ASYNC fusion as a base. It continues to be compatible with Fuseable publishers but now by default only negotiates `Fuseable.NONE`. Some RxJava adapter classes don't really have a way of propagating the fusion up to RxJava and used to rely on the default ASYNC capability of MonoSubscriber, testing that `requestFusion` would indeed negotiate that. Now that it negotiates NONE, said tests fail. This commit removes the tests and adds a FIXME as a more in depth follow up to this issue (where we can evaluate if it makes sense to keep the publishers Fuseable). Also update to latest 3.4.x core snapshot. See reactor/reactor-core#3245.
violetagg
added a commit
to reactor/reactor-kotlin-extensions
that referenced
this pull request
Nov 8, 2022
In reactor-core, `Operators.MonoSubscriber` has stopped implementing ASYNC fusion as a base. It continues to be compatible with Fuseable publishers but now by default only negotiates `Fuseable.NONE`. Some RxJava adapter classes don't really have a way of propagating the fusion up to RxJava and used to rely on the default ASYNC capability of MonoSubscriber, testing that `requestFusion` would indeed negotiate that. Now that it negotiates NONE, said tests fail. This commit removes the tests and adds a FIXME as a more in depth follow up to this issue (where we can evaluate if it makes sense to keep the publishers Fuseable). Also update to latest 3.4.x core snapshot. See reactor/reactor-core#3245.
chemicL
pushed a commit
that referenced
this pull request
Mar 7, 2023
Since Mono deals with at most one item, a notion of a queue is not justified. MonoSubscriber supported the notion of async fusion, which requires unnecessary operations to support it. This contributes to a performance degradation instead of improving it. Async fusion has been removed in 3.5.0 line as part of a rework of Mono stack to make them more lazy (compute result after request has been issued, instead of at subscription time). The asynchronous fusion aspect can be also removed as part of the 3.4.x release line to improve performance of existing usages, as it does not change the behaviour nor the APIs. Fixes #3239
chemicL
pushed a commit
that referenced
this pull request
Mar 7, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #3239