We still need to decide on the reset vs shutdown distinction: #3022 (comment)

What is your perspective? Do you have a strong opinion one way or another?

With start/shutdown, there is a clear intention to stop everybody. With reset, any running code could respawn the threads and the new threads will resume leaking. I prefer start/shutdown.

Agree, it will be great to have ability to stop Schedulers and prevent new workers from scheduling for apps that run in Servlets and other similar containers which can be stopped externally.

I'm happy with the start/shutdown pair which seems to support my primary use cases:

• resource release on webapp shutdown in container
• resource release on completion of programs run by a framework that looked for unreleased threads (maven)
• on ad-hoc basis ensuring schedulers are not running in the background on entry into a unit test (when running a suite)

Thanks @akarnokd!

the start/shutdown semantic looks good to me, more explicit, best enforcement of shutdown 👮 and good compatibility with items mentioned by @davidmoten (which are pretty much our use cases as well) 👌

I'll following this thread to be notified when it's merged. Thanks @akarnokd

@benjchristensen do you consider we have consensus on naming? after that it'd be showtime 🎬 😂

🆙 because so many customers from us run into this.

@daschl 👍

I would like a bit more context on what the goal is for the scheduler shutdown capability. @davidmoten and any others, please respond. Thanks.

resource release on webapp shutdown in container

What resources exactly need to be freed? Shutting down the schedulers would prevent new workers from being scheduled and would free up threads from the executor. Is this the desired behavior or is there some side effect that you are looking for?

resource release on completion of programs run by a framework that looked for unreleased threads (maven)

Could anyone name a framework that's impacted? Is the concern that open threads keep the framework from properly terminating?

on ad-hoc basis ensuring schedulers are not running in the background on entry into a unit test (when running a suite)

Would the TestScheduler solve this problem for you? This doesn't rely on singleton values and can be used to precisely test scheduling behavior.

@stealthcode I can answer the question 2. I hope it help you.

Could anyone name a framework that's impacted? Is the concern that open threads keep the framework from properly terminating?

• Couchbase Java SDK

CB SDK are not able to finish some of they own threads because it is referring RxComputationThreadPool threads who can't be finished.

You can see more details about how this issue are affecting this framework here.
https://forums.couchbase.com/t/the-v2-of-the-java-client-leaks-rxjava-threads-on-shutdown/3890/19

@stealthcode I can give you the answer to your questions, too.

I'd like to use RxJava in the container (e.g. I'd like to use Jersey Rx Client on Tomcat). Unfortunately, it is impossible to shutdown RxComputationThreadPool-* threads and container has memory leaks. That causes that RxJava is inapplicable for my purposes :( And in my case - regarding question 1 - yes, shutting down all schedulers permanently is a desired behaviour. And TestScheduler is not a solution.
So, I'm really looking forward to seeing this PR accepted and released!

@mjakubowski84 👍 similar case here.

@mjakubowski84 understood. regarding the TestScheduler - this is meant for use in tests and highly recommended. When it comes to a container you would definitely want to use a real scheduler.

So, what I hear is that there is no desire to resume the scheduler once it is shut down. My concern is that by offering a SchedulerLifecycle.start() method we are inviting non-deterministic behavior in the case that someone wants to use this to teardown and then resume (in integration tests for example). Would it be acceptable to remove the start() method from the public interface and rename shutdown() to teardown() to more accurately describe the intent?

I don't have strong opinion between shutdown/teardown.
teardown makes the intent clearer, but shutdown is more idiomatic (in the context of java executor).

Otherwise the code LGTM 👍

Another thing, if we want to be more java idiomatic, maybe hiding the start() is the right thing to do.
It will also have the benefit of avoiding bug by misusage of the library (calling start() after a shutdown()).

I can make Schedulers.start() package private so the tests can use it but I the Scheduler implementations have to keep their start public.

Please do, I believe that would be better.

Done.

@akarnokd @stevegury folks, do you think its possible to get this into 1.0.15?

@akarnokd thanks.

I think this is fine 👍

Do you guys have a plan date to merge it?

@akarnokd I think it's appropriate that you merge this PR since you are most familiar with this code. If you think you are happy with it then feel free.

Oh, sorry, didn't recount the number of likes. Merging.

Where can I get the latest build with this fix? Maven central is still at 1.0.14.

@chiangh123 you can clone the project and build it from master. Good luck :)

RxJava uses bintray for binaries and also publishes snapshots in JFrog's OSS artifactory, so you can add the following repository to your pom.xml:

<repository>
  <snapshots />
  <id>snapshots</id>
  <name>libs-snapshot</name>
  <url>http://oss.jfrog.org/artifactory/libs-snapshot</url>
</repository>

After that you should be able to depend on rxjava 1.0.15-SNAPSHOT.