RxRatpack.initialize() causes Schedulers.io() to return fixed-thread-pool-Scheduler

[jonpeterson]

I'll start by saying that I'm still learning RxJava, but I believe I understand that the concept of the Schedulers.io() scheduler is that new threads are spawned as needed.

ratpack-rx's DefaultSchedulers only implements getComputationScheduler() to return a MultiExecControllerBackedScheduler. (https://github.com/ratpack/ratpack/blob/v1.4.6/ratpack-rx/src/main/java/ratpack/rx/internal/DefaultSchedulers.java)

drmaas/ratpack-rx2's DefaultSchedulers implements both getComputationScheduler() and getIoScheduler() to return a MultiExecControllerBackedScheduler. (https://github.com/drmaas/ratpack-rx2/blob/master/src/main/java/ratpack/rx2/internal/DefaultSchedulers.java)

Ultimately both the ratpack-rx and drmaas/ratpack-rx2 implementations of MultiExecControllerBackedScheduler both end up mapping back to an EventLoopGroup with a fixed number of threads. (https://github.com/ratpack/ratpack/blob/v1.4.6/ratpack-core/src/main/java/ratpack/exec/internal/DefaultExecController.java#L60)

I'm sure you had a reason for setting Schedulers.io() to a Ratpack handled one, but when I reset Schedulers.io() back to the default RxJava one, I no longer experience deadlocks in areas of my application with complex logic and database calls.

Work-around:

...
RxRatpack.initialize();
RxJavaPlugins.setInitIoSchedulerHandler(null);
...

[jonpeterson]

I started running into different issues after implementing the workaround ("Operation attempted on non Ratpack managed thread"). I went back and kept searching and found that my root issue ended up being something else entirely (not realizing that delay() defaulted to Schedulers.compute()).

Going to close this.