Limit the number of threads created by the elastic scheduler #1804
Comments
bsideup
added
status/need-design
|
As discussed off-band, I really favor the alternative where we don't touch the current The underlying implementation can be a simple additional parameter to There will be a need for a documentation that provides a good transition path, so that users accustomed to Two open questions remain:
|
simonbasle
removed
status/need-triage
warn/behavior-change
|
Perhaps we can ask help from our Spring friends who most probably already did a research on the default pool size for async tasks (I am thinking pre-Reactive era) |
|
|
|
After further discussion with the team, the benefit of offering this new So we'll work with several of these projects to evaluate the behavior of The good news is that the approach taken will allow smooth transitioning from |
|
Tested changes in Spring Framework and Spring Boot, with |
Prior to this commit, Spring Framework would use `Schedulers.elastic()` in places where we needed to process blocking tasks in a reactive environment. With reactor/reactor-core#1804, a new `Schedulers.boundedElastic()` scheduler is available and achieves the same goal with added security; it guarantees that resources are bounded. This commit uses that new scheduler in the standard websocket client, since the underlying API is blocking for the connection phase and we need to schedule that off a web server thread. Closes gh-23661 See gh-23665
Prior to this commit, Spring Boot would use `Schedulers.elastic()` when required to process blocking tasks in a reactive environment. reactor/reactor-core#1804 introduced a new scheduler, `Schedulers.boundedElastic()` that behaves quite similarly but: * will limit the number of workers thread * will queue tasks if no worker thread is available and reject them is the queue is exceeds a limit This allows Spring Boot to schedule blocking tasks as before and allows greater flexibility. Fixes gh-18269 See gh-18276
Prior to this commit, Spring Boot would use `Schedulers.elastic()` when required to process blocking tasks in a reactive environment. reactor/reactor-core#1804 introduced a new scheduler, `Schedulers.boundedElastic()` that behaves quite similarly but: * will limit the number of workers thread * will queue tasks if no worker thread is available and reject them is the queue is exceeds a limit This allows Spring Boot to schedule blocking tasks as before and allows greater flexibility. Fixes spring-projectsgh-18269 See spring-projectsgh-18276
While introducing the singleton version of BoundedElasticScheduler, we might as well make it truly bounded, including in the number of task submissions it can "absorb" during a spike. Used to be unbounded, now bounded to 100K tasks. This is also more likely to uncover problematic scheduling of blocking tasks. Users switching from `elastic()` to `boundedElastic()` and seeing `RejectedExecutionException`s should challenge why their Reactor app schedules so many blocking tasks, and if still legitimate and necessary, use a `newBoundedElastic` instance that is better tuned to their workload. Reviewed-in: #1900
The current implementation of ElasticScheduler does not limit the number of threads created by it.
Since we recommend using it for blocking APIs, it may lead to a problem when there are too many blocking calls and the scheduler will create 1000s of threads.
To avoid that, we should consider limiting the total number of threads and queue the tasks if all threads are busy.
Things to consider
Alternative
Introduce a new
Schedulers.blocking()that will be elastic but limit the amount of threads (should be clearly stated in the docs, so that the users understand the potential of having a deadlock as described in "things to consider").It could be a nice alternative given the elastic nature of both, and even there is some old code that uses
elastic, their usage will not dramatically affect the app because their threads will eventually be terminated.The text was updated successfully, but these errors were encountered: