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
As of reactor/reactor-core#1804, Reactor core will provide a new Scheduler implementation,
Schedulers.boundedElastic().This implementation, unlike
elasticdoes 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
Schedulersin 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 placesReactorNettyTcpClientis using a specific parallel scheduler; this use case seems valid and we should not change this