Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scheduler graceful dispose should share awaitTermination monitoring threads #3258

Closed
chemicL opened this issue Oct 28, 2022 · 0 comments · Fixed by #3259
Closed

Scheduler graceful dispose should share awaitTermination monitoring threads #3258

chemicL opened this issue Oct 28, 2022 · 0 comments · Fixed by #3259
Labels
type/enhancement A general enhancement

Comments

@chemicL
Copy link
Member

chemicL commented Oct 28, 2022

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.

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 Schedulers 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

@chemicL chemicL added the type/enhancement A general enhancement label Oct 28, 2022
@simonbasle simonbasle linked a pull request Nov 4, 2022 that will close this issue
chemicL pushed a commit that referenced this issue Mar 7, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement A general enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant