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
As of reactor/reactor-core#1804, Reactor core will provide a new Scheduler implementation, Schedulers.boundedElastic().
This implementation, unlike elastic does not create an unbounded number of threads; it creates a bounded number of workers and will queue tasks if there are no worker available. This implementation is a direct replacement for the elastic one, as it limits the amount of resources.
Spring Framework is currently using alternate Schedulers in several places:
a Schedulers.elastic() in StandardWebSocketClient, because the connection phase is blocking. We should improve there and use boundedElastic() instead. While this might not provide big runtime improvements, it's compatible with the existing choice and it should be beneficial to use this scheduler since it should be used in most places
the ReactorNettyTcpClient is using a specific parallel scheduler; this use case seems valid and we should not change this
The text was updated successfully, but these errors were encountered:
As of reactor/reactor-core#1804, Reactor core will provide a new Scheduler implementation,
Schedulers.boundedElastic()
.This implementation, unlike
elastic
does not create an unbounded number of threads; it creates a bounded number of workers and will queue tasks if there are no worker available. This implementation is a direct replacement for the elastic one, as it limits the amount of resources.Spring Framework is currently using alternate
Schedulers
in several places:Schedulers.elastic()
inStandardWebSocketClient
, because the connection phase is blocking. We should improve there and useboundedElastic()
instead. While this might not provide big runtime improvements, it's compatible with the existing choice and it should be beneficial to use this scheduler since it should be used in most placesReactorNettyTcpClient
is using a specific parallel scheduler; this use case seems valid and we should not change thisThe text was updated successfully, but these errors were encountered: