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

• this will be a behaviour change and potentially may break existing code, because if the tasks are scheduled recursively (a task submitted to the elastic scheduler submits a few more tasks to it) and wait for them, and the thread pool size is 100, then 101 task will wait forever because all other threads will be waiting
• Thread pool's size is always a pain to predict / do right

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.