-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Flowable scan operators backpressure inconsistency #7109
Comments
It is by design due to how asynchronous requesting can interact with that very first value emission vs the upstream. For example, the upstream may be completing asynchronously without any value exactly the time when the downstream requests 1 item (the initial value) thus there is a race and need for serialization. The straightforward solution is to use prefetching + queue just like many other operators, consequently, the downstream request pattern is lost in the process. The prefetch amount is currently not exposed on the |
Many thanks for clarifying that. Is it worth documenting the behavioural difference in the operator javadoc? Edit: or perhaps provide a new BackpressureSupport value (like BUFFERED_IN) |
Their documentation could include an expanded * <dl>
* <dt><b>Backpressure:</b></dt>
* <dd>
+ * The downstream request pattern is not preserved across this operator.
+ * The upstream is requested {@link #bufferSize()} - 1 upfront and 75% of {@link #bufferSize()} thereafter.
* </dd> Would you like to create a PR for such documentation change?
Not likely. |
No problem. Will do |
Hello,
Flowable operator scan (without initial value) pulls values according to downstream requests, but other scan variations will pull in buffersize() chunks.
RxJava version: 3.0.7
Code (if kotlin is not acceptable, let me know and I will amend to a Java version):
only the second test passes.
Trace:
My expectation would be that after supplying the initial value, the remaining values would be requested up as the downstream requires (akin to the no initial value scan).
The text was updated successfully, but these errors were encountered: