-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable fusion in MonoSubscriber #3245
Disable fusion in MonoSubscriber #3245
Conversation
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Switched to arbitrary operator that satisfies .expectFusion(Fuseable.ASYNC)
Need to fix some tests that depended on certain operators being fuseable |
@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 Yes will clean this up in the next few days -- must have missed it, thanks! |
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.
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.
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.
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.
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
Fixes #3239