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
Using ExecutionModel.SynchronousExecution has some very surprising and dangerous consequences that are not mentioned in its documentation.
Namely, the value of ExecutionModel.recommendedBatchSize (which is close to Int.MaxValue for SynchronousExecution) is used as default buffer size when converting a Reactive Streams Publisher to Observable (Observable.fromReactivePublisher). This basically means that the buffer becomes unbounded and effectively turns off backpressure and quickly exhausts available memory, leading to catastrophic failures.
My understanding of ExecutionModel.recommendedBatchSize (as explained by its documentation) is that it only affects the internal trampoline of Scheduler, controlling the frequency of asynchronous boundaries. In my opinion it should not affect other places like the culprit buffer size.
The text was updated successfully, but these errors were encountered:
Using
ExecutionModel.SynchronousExecution
has some very surprising and dangerous consequences that are not mentioned in its documentation.Namely, the value of
ExecutionModel.recommendedBatchSize
(which is close toInt.MaxValue
forSynchronousExecution
) is used as default buffer size when converting a Reactive StreamsPublisher
toObservable
(Observable.fromReactivePublisher
). This basically means that the buffer becomes unbounded and effectively turns off backpressure and quickly exhausts available memory, leading to catastrophic failures.My understanding of
ExecutionModel.recommendedBatchSize
(as explained by its documentation) is that it only affects the internal trampoline ofScheduler
, controlling the frequency of asynchronous boundaries. In my opinion it should not affect other places like the culprit buffer size.The text was updated successfully, but these errors were encountered: