You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason it was never bounded in v1 is that it causes these types of hidden system hangs that are very hard to debug. This seems like a dangerous behavior to have changed.
Yes, you have to unbound Flowable.flatMap manually for your use case as it defaults to a fixed number of active inner Publishers at once; this is a typical behavior for in-sequence operators that have an N:M relation between the input and output because Flowable is the backpressure-enabled, no-overflow base reactive type.
If you need unbounded behavior, consider using Observable. In v1, there was a theoretical problem when the same bounding on merge was attempted: GUI scenarios may merge more than 128 sources at once and bounding merge that late in the life of v1 could have caused unexpected hangs indeed.
The Javadoc has been fixed by and closing via #5127.
When more than 128 publishers that not all emit events causes miss of any further message that would be sent by subsequent publishers. This is due to the underlying implementation defaults to bufferSize() which is 128 https://github.com/ReactiveX/RxJava/blob/2.x/src/main/java/io/reactivex/Flowable.java#L8239
According to http://reactivex.io/RxJava/javadoc/io/reactivex/Flowable.html#flatMap(io.reactivex.functions.Function)
Example to replicate the issue: (assumes that publishers is greater than 128 and that none of the first 128 publishers are emitting any message):
At the moment the work around is to use the overloaded flatMap to set manually set maxConcurrency to be unbounded.
The text was updated successfully, but these errors were encountered: