-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Backpressure: replay #1487
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
Comments
I might not be able to do this before September. In addition, the backpressure support would need to turn the BehaviorSubject and PublishSubject into a ReplaySubject-like construct. I think they can support backpressure all the way through without trouble. The difficulty may come from the ability in BehaviorSubject and PublishSubject that makes sure no values in a sequence get lost while a client subscription procedure is going on. |
A multicasting Subject can not support backpressure. It's hot and each Subscriber needs to choose its own strategy (drop, buffer, etc). Therefore, this change for |
See #3047. |
Done and shipped via 1.0.14. |
The
replay
operators andReplaySubject
should respect backpressure for the downstream while replaying back. Depending on the variant ofreplay
(such as unbounded buffering) it could support it even in multicast mode. For the variants that don't do unbounded buffering, then once it finishes replying the cached values, then it can no longer support backpressure (due to multicasting), but it's still good to support it during replay, as that can be a very rapid firehose whereas it could be quite slow once caught up.The text was updated successfully, but these errors were encountered: