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
With graceful disposal of Schedulers, a monitor thread is started to call ExecutorService.awaitTermination(). Each Scheduler, upon a subscribe to Scheduler#disposeGracefully() creates a separate Thread. There should be a shared pool of such Threads and a smart way to iterate over disposed instances.
This change introduces a `DisposeAwaiterRunnable` with a small pool of
threads dedicated to polling the termination status after a graceful
Scheduler shutdown.
Previously, one Thread would be created for each Scheduler that is
disposed gracefully. While we don't expect this to be an issue in most
production applications, this can lead to hitting native thread limits
faster. Notably, stress tests around graceful disposal create a lot of
schedulers for that purpose.
This change also ensures that the evictor executorServices of both the
BoundedElasticScheduler and ElasticScheduler are limited to at most 1
thread.
Finally, it attempts to improve the SchedulersStressTest to avoid the
OOMs as much as possible: block on disposeGracefully() calls, increase
the heap of forked JVMs for jcstress, and ultimately stop covering the
BoundedElasticScheduler in the stress test.
Fixes#3258.
With graceful disposal of
Scheduler
s, a monitor thread is started to callExecutorService.awaitTermination()
. Each Scheduler, upon a subscribe toScheduler#disposeGracefully()
creates a separateThread
. There should be a shared pool of suchThread
s and a smart way to iterate over disposed instances.The current approach is troublesome in stress tests and sometimes causes OOM issues, e.g.:
https://github.com/reactor/reactor-core/actions/runs/3340954130/jobs/5531669637
It should be less probable in real-world applications, but still if multiple
Scheduler
s are in use, they should use as few resources as necessary.There is already a TODO in the code pointing to where the change needs to be applied: https://github.com/reactor/reactor-core/blob/d17512947028d9689199b84d84941895f740d[…]r-core/src/main/java/reactor/core/scheduler/SchedulerState.java
The text was updated successfully, but these errors were encountered: